Module 05 Summary
The idea this module was built around
A join is not "adding columns". It is a row-matching operation, and when one side has several matching rows the other side gets repeated - along with every value you were about to sum.
What you can now do
- Predict the row count of a join before running it
- Pre-aggregate the many-side so that totals stay correct
- Choose the join type from what the question asks, not from habit
The trap this module removed
Order 501 has an order_total of ₹1,000.00 and three line items. Joined to order_items, SUM(order_total) returns ₹3,000.00 for that one order - the value counted once per line. Across the table that turns the true ₹27,01,463 into ₹91,47,789. The query contains no error message, no warning, and nothing that looks wrong; only the number is wrong.
The second half is the mirror image. Counting customers who have never ordered is impossible with an inner join, which discards exactly the rows you are looking for and returns 0. LEFT JOIN ... WHERE order_id IS NULL returns the real answer: 3,812.
Figures worth remembering
1,000 orders joined to 3,400 line items produces 3,400 rows. COUNT(*) before and after a join is the cheapest safety check in SQL.
Before you move on
If you remember one thing from this course, make it this: after every join, check whether the row count changed, and whether you meant it to.