Karim from Finance asks: “What was our 2025 revenue by product category?” Revenue lives on order_items, the year lives on orders, and the category name lives on categories, two steps away via products. No single table answers the question. Joins put them together, and getting them right is mostly about knowing which rows each join keeps.
Each join needs a condition that says which rows belong together, almost always a key: order_items.order_id points to orders.order_id, order_items.product_id to products.product_id, and so on. For Cartwheel, revenue counts every order except cancelled ones.
SELECT\n c.name AS category,\n COUNT(DISTINCT o.order_id) AS orders,\n ROUND(SUM(oi.quantity * oi.unit_price * (1 - oi.discount)), 2) AS revenue\nFROM orders AS o\nJOIN order_items AS oi ON oi.order_id = o.order_id\nJOIN products AS p ON p.product_id = oi.product_id\nJOIN categories AS c ON c.category_id = p.category_id\nWHERE o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nGROUP BY c.name\nORDER BY revenue DESC;Desks & Chairs leads with about 77,000. Two rows look odd, though: “Kitchen” and “Outdoor” are top-level categories, and products are supposed to sit in sub-categories. Keep that in mind; it’s a data-quality finding you’ll chase in Section 4.
\nTwo habits make join queries readable and safe. Short aliases (o, oi, p, c) keep lines short. And qualifying every column with its alias removes guesswork, which matters here: order_items.unit_price is the price charged on the day, products.unit_price is today’s list price. An unqualified unit_price in this query is an “ambiguous column name” error, and picking the wrong one silently changes revenue.
COUNT(DISTINCT o.order_id) is deliberate too. After joining to items, each order appears once per item line, so COUNT(*) would count lines. That repetition is the subject of the next lesson.
JOIN means INNER JOIN: a row survives only if it finds a match on the other side. That’s right for revenue, where an item without an order would be meaningless. It’s wrong when the question is about everything on one side, including things with no matches.
Julia asks for each Operations employee’s ticket count, “including people who don’t handle tickets, so I can see who could help in peak season”:
\nSELECT\n e.employee_id,\n e.first_name,\n e.title,\n COUNT(t.ticket_id) AS tickets\nFROM employees AS e\nLEFT JOIN support_tickets AS t\n ON t.agent_id = e.employee_id\nWHERE e.department = 'Operations'\nGROUP BY e.employee_id\nORDER BY tickets DESC;Eight rows. The four agents have about 200 tickets each; Mark, Samir, Ben and Adam have 0. A LEFT JOIN keeps every row of the left table, here employees, and where no ticket matches, the ticket columns are NULL. COUNT(t.ticket_id) skips those NULLs, which is why the non-agents show 0 rather than 1.
Now Julia narrows it: “Same list, but count only urgent tickets.” The natural edit adds AND t.priority = 'urgent' to the WHERE clause, and the four non-agents disappear. Their rows have t.priority NULL, the condition is NULL, and WHERE drops them. A right-table filter in WHERE turns a LEFT JOIN back into an INNER JOIN.
The filter belongs in the ON clause, where it decides which tickets match, not which rows survive:
SELECT\n e.first_name,\n COUNT(t.ticket_id) AS urgent_tickets\nFROM employees AS e\nLEFT JOIN support_tickets AS t\n ON t.agent_id = e.employee_id\n AND t.priority = 'urgent'\nWHERE e.department = 'Operations'\nGROUP BY e.employee_id\nORDER BY urgent_tickets DESC;Eight rows again, with zeros where they belong. The rule: conditions on the left table go in WHERE; conditions on the right table go in ON.
\nA reliable way to decide: start FROM the table whose rows you want in the answer, the one that matches the grain you wrote down. Then ask of every other table, “is this information required or optional?” Required information gets an inner join, because a row without it shouldn’t be in the answer. Optional information gets a LEFT JOIN, so missing matches show up as NULLs you can count, label or turn into zeros.
For Julia’s list the answer is about employees, so employees comes first, and tickets are optional. For Karim’s revenue the answer is about sales, so every table in the chain is required.
SQLite also supports RIGHT JOIN and FULL OUTER JOIN (since version 3.39), and PostgreSQL has had them for decades. You’ll rarely need them: a right join is a left join with the tables swapped, and most teams write everything as LEFT JOIN so queries read the same way, top to bottom, from the main table outwards.
Finally, check the row count after each join you add. If employees filtered to Operations has 8 rows, the LEFT JOIN plus GROUP BY must also return 8. A number that grows or shrinks unexpectedly tells you a join is doing something you didn’t intend.
The category revenue had one more trap that didn’t bite, because revenue sat on the most detailed table. When a number lives on the less detailed side of a join, sums inflate. That’s next.
\n","toc":[{"id":"sec-1","text":"Following the keys","level":2},{"id":"sec-2","text":"INNER versus LEFT","level":2},{"id":"sec-3","text":"ON versus WHERE in a LEFT JOIN","level":2},{"id":"sec-4","text":"Choosing the join, and the starting table","level":2}],"takeaways":["An INNER JOIN keeps only rows that match on both sides; a LEFT JOIN keeps every row from the left table and fills unmatched right-side columns with NULL.","Give every table a short alias and qualify every column, especially names like unit_price that exist in more than one table.","A filter on the right table of a LEFT JOIN belongs in the ON clause; in WHERE it removes the NULL rows and turns the join back into an inner join.","Count a right-table column, not *, after a LEFT JOIN, so unmatched rows count as 0 instead of 1."],"further":[{"title":"SQLite SELECT, the FROM clause and joins","url":"https://www.sqlite.org/lang_select.html#fromclause"},{"title":"PostgreSQL tutorial on joins between tables","url":"https://www.postgresql.org/docs/current/tutorial-join.html"}],"quiz":[{"q":"orders has 2,066 rows and order_items has 3,991. Every order has at least one item. How many rows does orders o JOIN order_items oi ON oi.order_id = o.order_id return?
This should list every UK customer with their marketplace order count, zero included. Why do customers with no marketplace orders vanish?
\nSELECT c.customer_id, COUNT(o.order_id) AS marketplace_orders\nFROM customers c\nLEFT JOIN orders o ON o.customer_id = c.customer_id\nWHERE c.country = 'United Kingdom'\n AND o.channel = 'marketplace'\nGROUP BY c.customer_id;COUNT(o.order_id) should be COUNT(*).","why":"The counting expression isn’t the problem; the missing customers never reach the GROUP BY at all."},{"text":"The o.channel test is NULL for customers without a matching order, so WHERE removes them.","why":"Correct. Move AND o.channel = 'marketplace' into the ON clause; the country test stays in WHERE because it’s about the left table."},{"text":"LEFT JOIN only keeps unmatched rows from the right table.","why":"It’s the other way round. LEFT JOIN preserves every row of the left table, here customers."}],"answer":1},{"q":"SELECT unit_price FROM order_items oi JOIN products p ON p.product_id = oi.product_id fails. Why?
unit_price exists in both tables, so the name is ambiguous.","why":"Correct. Write oi.unit_price (the price charged) or p.unit_price (the list price). They’re different numbers after the March 2025 price rise."},{"text":"You can’t select a column that was used in a join.","why":"Any column can be selected; the join key isn’t involved here anyway."},{"text":"Aliases must be declared with AS.","why":"AS is optional for table aliases in SQLite and PostgreSQL."}],"answer":0},{"q":"After employees e LEFT JOIN support_tickets t ON t.agent_id = e.employee_id, which expression gives 0 tickets for employees who handled none?
COUNT(*)","why":"An unmatched employee still produces one row (with NULL ticket columns), so COUNT(*) returns 1."},{"text":"COUNT(e.employee_id)","why":"The employee id is never NULL, so this also counts the unmatched row as 1."},{"text":"COUNT(t.ticket_id)","why":"Correct. The ticket id is NULL on the unmatched row, and COUNT skips NULLs."},{"text":"SUM(t.ticket_id)","why":"That adds up id numbers, which is meaningless, and returns NULL for unmatched employees."}],"answer":2}],"exercise":{"kind":"sql","starter":"-- Every Jordan customer with their 2025 orders (zero included)\nSELECT\n c.customer_id,\n c.first_name,\n COUNT(o.order_id) AS orders_2025\nFROM customers AS c\nLEFT JOIN orders AS o\n ON o.customer_id = c.customer_id\nWHERE c.country = 'Jordan'\n AND o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nGROUP BY c.customer_id;","solution":"SELECT\n c.customer_id,\n c.first_name,\n COUNT(o.order_id) AS orders_2025\nFROM customers AS c\nLEFT JOIN orders AS o\n ON o.customer_id = c.customer_id\n AND o.status <> 'cancelled'\n AND o.order_date >= '2025-01-01'\n AND o.order_date < '2026-01-01'\nWHERE c.country = 'Jordan'\nGROUP BY c.customer_id, c.first_name;","orderMatters":false,"title":"Every Jordan customer, zeros included","prompt":"Huda is planning a win-back email for Jordan and needs every customer in Jordan with the number of non-cancelled orders they placed in 2025, showing 0 for customers who didn’t order.
\nReturn customer_id, first_name and orders_2025. Row order doesn’t matter. Jordan has 32 customers, so expect 32 rows; the starter returns fewer.
o.status and o.order_date values after the LEFT JOIN?","Conditions on the right table (orders) decide which orders match. They belong in the ON clause.","Keep c.country = 'Jordan' in WHERE (it’s about the left table) and move the status and date tests into ON ... AND ...."],"explanation":"For a Jordan customer with no 2025 orders, the LEFT JOIN produces one row with every o. column NULL. In the starter, o.status <> 'cancelled' is NULL for that row, so WHERE throws it away and the customer disappears. Moving the order conditions into ON means they only decide which orders attach; the customer row survives either way, and COUNT(o.order_id) counts 0 for it. Nine customers had no 2025 orders, exactly the ones a win-back email is for.