Start hereHow does SQL turn tables into evidence?
SQL declares the result you want; the database engine determines an execution plan. The learner’s job is to reason about row grain, filters, joins and aggregation.
Building interactive view…
Technical lensFormalise what the visual is doing
Logical query processing can be reasoned about as FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY, even though the optimiser may execute differently.
Technical questionUse a tiny case to make the mechanism observable. Logical query processing can be reasoned about as FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY, even though the optimiser may execute differently. Verify one intermediate quantity, state change or mapping independently; then predict the consequence of this change: Change an inner join to a left join and predict which entities reappear.
Practitioner lensUse it responsibly
Validate join cardinality and aggregation grain. A syntactically correct query can still answer the wrong business question.
Transfer testTransfer this idea to a new example and justify each decision using this practitioner rule: Validate join cardinality and aggregation grain. A syntactically correct query can still answer the wrong business question. Then explain what should change if you deliberately test: Change an inner join to a left join and predict which entities reappear.
Worked explorationUse the visual as an experiment, not decoration
Use a small orders table. Apply FROM/JOIN, then WHERE, GROUP BY and SELECT logically. Predict how moving a condition from WHERE to HAVING changes whether it filters raw rows or aggregated groups.
Technical lens
Logical query processing can be reasoned about as FROM/JOIN → WHERE → GROUP BY → HAVING → SELECT → ORDER BY, even though the optimiser may execute differently.
Practitioner check
Validate join cardinality and aggregation grain. A syntactically correct query can still answer the wrong business question.
Prediction before interactionChange an inner join to a left join and predict which entities reappear.
Exploration walkthroughTurn the interaction into an evidence trail
Use a small orders table. Apply FROM/JOIN, then WHERE, GROUP BY and SELECT logically. Predict how moving a condition from WHERE to HAVING changes whether it filters raw rows or aggregated groups. Before moving the control, state your prediction. After the visual changes, name the specific state, statistic, boundary or mapping that changed and explain why that change is consistent—or inconsistent—with your prediction.
- Record one observable quantity before the interaction and the same quantity afterwards.
- Change one factor at a time so the causal effect of the control is inspectable.
- Use an edge or failure case to discover where the concept stops behaving as the simple story suggests.
