Two requests arrive on the same morning. Rania, the CEO, wants a clean list of who reports to whom before a reorganisation. Huda wants to know which customers signed up and never bought anything. They look unrelated, but both are about relationships between rows: one follows a link within a table, the other looks for links that are missing.
\nIn employees, manager_id holds the employee_id of another row in the same table. To show each employee next to their manager’s name, you join employees to itself. The trick is two aliases, one per role:
SELECT\n e.first_name || ' ' || e.last_name AS employee,\n e.title,\n m.first_name || ' ' || m.last_name AS manager\nFROM employees AS e\nLEFT JOIN employees AS m\n ON m.employee_id = e.manager_id\nORDER BY e.department, manager;Read it as two copies of the table: e is the employee, m is the person they report to. The || operator concatenates text. A LEFT JOIN keeps Rania herself, whose manager_id is NULL; an inner join would quietly drop the CEO from the org chart, which is not a mistake you want to explain.
The same pattern works on customers.referred_by. Who brings in the most new customers?
SELECT\n r.customer_id,\n r.first_name || ' ' || r.last_name AS referrer,\n COUNT(*) AS customers_referred\nFROM customers AS c\nJOIN customers AS r ON r.customer_id = c.referred_by\nGROUP BY r.customer_id\nORDER BY customers_referred DESC, r.customer_id\nLIMIT 5;Here c is the new customer and r the referrer. Leo Ibrahim referred three people; nobody referred more. Naming aliases after roles (e/m, c/r) rather than a/b is what keeps self-joins readable.
Self-joins only go one level at a time: employee to manager. “Everyone in Peter’s organisation, at any depth” needs a recursive query, which you’ll write in the next section.
\nLast lesson, WHERE order_id IN (SELECT order_id FROM support_tickets) found orders with at least one ticket, without the fan-out a join would cause. That’s a semi-join. EXISTS is the other common spelling:
SELECT c.customer_id, c.email\nFROM customers AS c\nWHERE EXISTS (\n SELECT 1 FROM orders AS o\n WHERE o.customer_id = c.customer_id\n);The subquery is correlated: it refers to c from the outer query, so it’s evaluated per customer. SELECT 1 is a convention; EXISTS only cares whether any row comes back, not what’s in it.
Huda’s question is the opposite: customers with no orders. There are two reliable ways to write an anti-join. The first is NOT EXISTS:
SELECT\n strftime('%Y', c.signup_date) AS signup_year,\n COUNT(*) AS never_ordered\nFROM customers AS c\nWHERE NOT EXISTS (\n SELECT 1 FROM orders AS o\n WHERE o.customer_id = c.customer_id\n)\nGROUP BY signup_year;85 customers never ordered, and 52 of them signed up in 2024, at least a year before the data ends. That’s the actionable part for Huda: the 2025 sign-ups might still convert, the 2024 ones need a different campaign.
\nThe second way is a LEFT JOIN that keeps only the unmatched rows:
\nSELECT COUNT(*) AS never_ordered\nFROM customers AS c\nLEFT JOIN orders AS o ON o.customer_id = c.customer_id\nWHERE o.order_id IS NULL;Same 85. Test the right table’s key for NULL, because a key is never NULL on a real match. Both forms are standard and fast; most analysts prefer NOT EXISTS because it states the intent and can’t fan out.
\n\nReal anti-joins usually carry a condition: not “never ordered”, but “hasn’t ordered recently”. The condition goes inside the NOT EXISTS subquery, where it narrows which orders count as a match. Here are customers who bought in 2024 but not at all in 2025, a classic lapsed-customer list:
\nSELECT COUNT(DISTINCT c.customer_id) AS lapsed_customers\nFROM customers AS c\nJOIN orders AS o24\n ON o24.customer_id = c.customer_id\n AND o24.order_date < '2025-01-01'\nWHERE NOT EXISTS (\n SELECT 1 FROM orders AS o25\n WHERE o25.customer_id = c.customer_id\n AND o25.order_date >= '2025-01-01'\n);The join to 2024 orders fans out (a customer with five 2024 orders appears five times), so the query counts distinct customers. Putting the 2025 condition anywhere outside the subquery would change the meaning entirely, the same lesson as ON versus WHERE, one level deeper.
\n| Question | \nPattern | \n
|---|---|
| Rows that have a match, without duplicates | \nEXISTS or IN (subquery) | \n
| Rows that have no match | \nNOT EXISTS, or LEFT JOIN ... WHERE key IS NULL | \n
| Rows plus details of their match | \nJOIN (watch for fan-out) | \n
| Links within one table | \nSelf-join with role-named aliases | \n
That completes the join toolkit. The next section stacks these building blocks into longer analyses, starting with a way to name intermediate results so a 40-line query still reads top to bottom.
\n","toc":[{"id":"sec-1","text":"A table joined to itself","level":2},{"id":"sec-2","text":"Semi-joins: does a match exist?","level":2},{"id":"sec-3","text":"Anti-joins: who has no match?","level":2},{"id":"sec-4","text":"Anti-joins with conditions","level":2},{"id":"sec-5","text":"Which one to use","level":2}],"takeaways":["A self-join uses two aliases of the same table, one per role, such as e for the employee and m for the manager.","A semi-join (EXISTS or IN) keeps rows that have at least one match without multiplying them.","An anti-join keeps rows with no match; write it as NOT EXISTS or as LEFT JOIN … WHERE right_key IS NULL.","NOT IN returns no rows at all when its subquery contains a NULL, so avoid it with nullable columns or filter the NULLs out explicitly."],"further":[{"title":"SQLite expressions, EXISTS and IN operators","url":"https://www.sqlite.org/lang_expr.html#the_exists_operator"},{"title":"PostgreSQL subquery expressions","url":"https://www.postgresql.org/docs/current/functions-subquery.html"}],"quiz":[{"q":"employees has 24 rows and only the CEO has a NULL manager_id. How many rows does employees e JOIN employees m ON m.employee_id = e.manager_id return?
manager_id is NULL, so the inner join finds no manager row for her and drops her."},{"text":"23","why":"Correct. Each employee except the CEO matches exactly one manager. Use LEFT JOIN to keep the CEO with a NULL manager."},{"text":"576","why":"That’s 24 × 24, a cross join. The ON condition limits each employee to their own manager."}],"answer":1},{"q":"Some customers have referred_by NULL. What does SELECT COUNT(*) FROM customers WHERE customer_id NOT IN (SELECT referred_by FROM customers) return?
x NOT IN (..., NULL) is never TRUE."},{"text":"The number of customers who referred someone.","why":"NOT IN excludes matches, so it couldn’t return the referrers, and the NULL problem empties the result anyway."},{"text":"0","why":"Correct. For every customer, the comparison with the NULL in the list is unknown, so NOT IN is NULL or FALSE and WHERE drops the row."},{"text":"An error, because the subquery returns NULLs.","why":"SQL allows NULLs in an IN list; the query runs and silently returns 0."}],"answer":2},{"q":"Which query lists customers who have never placed an order?
","options":[{"text":"SELECT c.* FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id WHERE o.order_id IS NULL","why":"Correct. Customers without orders get a NULL o.order_id; customers with orders don’t, so the IS NULL test keeps exactly the non-buyers."},{"text":"SELECT c.* FROM customers c JOIN orders o ON o.customer_id = c.customer_id WHERE o.order_id IS NULL","why":"An inner join has already removed customers without orders, so nothing is left to find."},{"text":"SELECT c.* FROM customers c LEFT JOIN orders o ON o.customer_id = c.customer_id WHERE o.status IS NULL","why":"Close, and it happens to work because status is NOT NULL, but test the join key; a nullable column like coupon_code would let real buyers through."},{"text":"SELECT c.* FROM customers c WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id)","why":"That’s the semi-join, which keeps the opposite set, customers with at least one order."}],"answer":0}],"exercise":{"kind":"sql","starter":"-- Business customers who have never referred anyone\nSELECT customer_id, email, segment\nFROM customers\nWHERE segment IN ('enterprise', 'small_business')\n AND customer_id NOT IN (SELECT referred_by FROM customers);","solution":"SELECT c.customer_id, c.email, c.segment\nFROM customers AS c\nWHERE c.segment IN ('enterprise', 'small_business')\n AND NOT EXISTS (\n SELECT 1\n FROM customers AS r\n WHERE r.referred_by = c.customer_id\n );","orderMatters":false,"title":"Who hasn't referred anyone?","prompt":"Huda wants to pitch the referral programme to business accounts. List every customer in the enterprise or small_business segment who has never referred anyone (no other customer has their id in referred_by).
Return customer_id, email and segment. Row order doesn’t matter. The starter returns no rows at all; rewrite the anti-join so it works.
SELECT referred_by FROM customers LIMIT 10. What value does most of that column hold, and what does NOT IN do with it?","Rewrite the condition as NOT EXISTS (SELECT 1 FROM customers AS r WHERE r.referred_by = c.customer_id), giving the outer table the alias c.","Alternatively, keep NOT IN but filter the subquery: SELECT referred_by FROM customers WHERE referred_by IS NOT NULL."],"explanation":"The subquery behind NOT IN returns 600 values, 503 of them NULL. x NOT IN (..., NULL) can never be TRUE, because the unknown value might equal x, so every row is dropped. NOT EXISTS asks a yes/no question per customer (is there any customer whose referred_by is me?) and NULLs never match, so it behaves as intended: 88 business customers, 21 enterprise and 67 small business, have never referred anyone.