Module 02 Summary
The idea this module was built around
A question is answerable when three things are fixed: the population it covers, what one row represents, and the measure being asked for. Until all three are pinned, there is more than one correct answer, and you will produce one of them at random.
What you can now do
- Turn "how are sales looking?" into something with exactly one right answer
- Filter, sort, and limit with an understanding of the order SQL actually applies them
- Recognise when a filter is doing nothing, and say so rather than leaving it in
The trap this module removed
SQL does not run in the order it is written. FROM and WHERE are resolved before SELECT, which is why the standard rejects a select-list alias inside WHERE. DuckDB - the engine this course ships - accepts it anyway. That is convenient here and portable nowhere: the same query fails on PostgreSQL. Knowing the logical order is what lets you predict which engines will complain.
Figures worth remembering
988 completed orders - and every order in this database was placed in June 2026, so "in June" filters out nothing at all. The best answer states both facts, because the second one tells the requester which follow-up questions this data cannot answer.
Before you move on
Take a request someone sent you this month and rewrite it with population, grain, and measure made explicit. Most of the time you will discover you had been guessing at one of them.