SQL Joins and Set Operations Questions

Direct answer. A join adds columns by relating two tables through a key; a set operation stacks or compares whole result sets that already share the same shape, adding no new columns at all. Reaching for the wrong one produces either a result with the wrong number of rows (a join where you meant a set operation) or a result missing the relationship you needed (a set operation where you meant a join).

Structured elaboration. Two cases where a set operation is correct: combining monthly exports of the same report into one longer time series (UNION ALL: same columns, you just want more rows of the same shape), and comparing two snapshots of the same population to find what changed (EXCEPT/INTERSECT: again the same columns, but now you're asking a membership question rather than adding information). Two cases where a join is correct: enriching an orders table with the customer's name from a customers table (you need a NEW column, name, that orders doesn't have), and finding customers who have never placed an order (you're relating two DIFFERENT entities through a key, not stacking or comparing same-shaped rows).

Worked example. Using a join where a set operation was needed: if you wanted "combine this month's revenue rows with last month's revenue rows into one series" and instead wrote a JOIN on date between the two tables, you'd get one row per matching date pair with columns from BOTH months side by side, an entirely different (and probably useless) shape from the simple longer list you actually wanted; a UNION ALL is the one-line correct answer. Using a set operation where a join was needed: if you wanted "customers alongside their order count" and instead tried to UNION customers and orders together, the operation would fail outright (or produce nonsense) the moment the two tables don't have the identical column count and types, because UNION has no concept of "relate these through a key," only "stack these because they're the same shape."

Trade-offs and pitfalls. The duplicate and NULL handling differ sharply between the two: a join can silently multiply rows through an unexpected one-to-many relationship (fan-out), a failure mode that has nothing to do with NULLs at all, and a plain equality join predicate never matches two NULL keys to each other. A set operation instead dedups automatically (for UNION/INTERSECT/EXCEPT, though not UNION ALL) and, in most engines, treats two NULLs in the same column position as equal for that deduplication, the exact opposite NULL behavior from a join. Recognizing which shape a problem actually has, "I need to add information from elsewhere" versus "I need to stack or compare things that are already the same shape", is what should drive the choice, not which one happens to occur to you first.

Direct answer. Replace the comma-separated FROM list and its WHERE-clause join condition with an explicit JOIN ... ON, which makes the join relationship visible at the FROM clause itself rather than buried among unrelated filter conditions in WHERE.

Structured elaboration. The old comma style puts the tables to combine and the condition that relates them in two completely different places (FROM lists the tables, WHERE happens to contain the predicate that relates them), and SQL has no way to tell "this WHERE condition is the join key" apart from "this WHERE condition is an ordinary filter." If someone editing the query later removes or mis-edits that one WHERE clause (thinking it's just a filter, since nothing marks it as load-bearing), the query silently becomes a full Cartesian product between the two tables instead of erroring.

Worked example. customers(customer_id, name): (1, 'Alice'). orders(order_id, customer_id, amount): (100, 1, 150).

-- old style: the join condition is indistinguishable from an ordinary filter
SELECT c.customer_id, o.order_id
FROM customers c, orders o
WHERE c.customer_id = o.customer_id AND o.amount > 100;

-- explicit JOIN: the relationship is visible in the FROM clause itself
SELECT c.customer_id, o.order_id
FROM customers c
JOIN orders o ON c.customer_id = o.customer_id
WHERE o.amount > 100;

Both return the identical result here: (1, 100). The explicit version makes it obvious, just from reading FROM/JOIN, which condition is the relationship between the tables and which (the amount filter) is an independent business rule.

Trade-offs and pitfalls. The silent-Cartesian-product risk is the main practical reason most style guides ban the comma style outright, not just a stylistic preference: with an explicit JOIN, forgetting the ON clause entirely is at minimum a jarring omission that stands out on review (and, in most engines, doesn't even parse without one, unless you deliberately wrote CROSS JOIN), whereas losing one WHERE condition among several others reads as a small, easy-to-miss diff. The two forms are logically equivalent when written correctly, so this is entirely a defensive-coding argument, not a performance or correctness difference between the two syntaxes as such.

Direct answer. A self-join treats one table as if it were two: you join employees to itself, once playing the role of the employee and once playing the role of that employee's manager, matching manager_id on one side to employee_id on the other.

Structured elaboration. A LEFT JOIN (not INNER) is essential here, because the top of the org has manager_id = NULL, and an INNER JOIN would silently drop the top-level employee (or anyone else with no manager) since NULL matches nothing. The pattern generalizes: give the table two different aliases in the FROM clause, and join those aliases to each other on whatever relationship the rows encode (here, "reports to").

Worked example. employees(1,'Alice',manager_id=NULL), (2,'Bob',manager_id=1), (3,'Cara',manager_id=1), (4,'Dee',manager_id=2).

SELECT e.name AS employee_name, m.name AS manager_name
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.employee_id
ORDER BY e.employee_id;

Result: (Alice, NULL), (Bob, Alice), (Cara, Alice), (Dee, Bob).

Extending one level up (manager's manager) is just a second self-join on the same table with a third alias:

SELECT e.name AS employee_name, m.name AS manager_name, gm.name AS manager_of_manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.employee_id
LEFT JOIN employees gm ON m.manager_id = gm.employee_id
ORDER BY e.employee_id;

Result: (Alice, NULL, NULL), (Bob, Alice, NULL), (Cara, Alice, NULL), (Dee, Bob, Alice). Dee's manager is Bob, and Bob's manager is Alice, so Dee's manager-of-manager column correctly resolves to Alice.

Trade-offs and pitfalls. Chaining self-joins works cleanly for a fixed, small number of levels (one or two), because each level is just one more LEFT JOIN. It stops scaling the moment the number of levels is unknown or the hierarchy can be arbitrarily deep, at which point you need a recursive CTE instead, which walks the hierarchy level by level until it runs out of rows rather than hard-coding a fixed number of self-joins. The self-join approach is also easy to get wrong on the join direction: joining e.manager_id = m.employee_id gets you the employee's manager; joining the other way around gets you the manager's direct reports, which is a different (equally valid) question.

Direct answer. An equi-join matches rows using equality on the join columns (a.key = b.key); a non-equi join matches using any other comparison, inequality, range membership, or BETWEEN, most commonly to place a value into the bucket or tier it falls within.

Structured elaboration. The clearest real-world case is tiering: given a transaction amount and a table of tiers each defined by a min and max bound, you're not looking for an EXACT match on amount, you're looking for the tier whose range CONTAINS that amount, which is inherently a range (non-equi) condition rather than an equality.

Worked example. pricing_tiers(tier_name, min_amount, max_amount): ('bronze', 0, 100), ('silver', 100, 500), ('gold', 500, 999999999).

SELECT t.amount, tier.tier_name
FROM transactions t
JOIN pricing_tiers tier
  ON t.amount >= tier.min_amount AND t.amount < tier.max_amount;

A transaction of amount=250 matches the 'silver' row because 250 falls between 100 and 500; there's no single equality condition that could express this relationship.

Trade-offs and pitfalls. Equi-joins are what B-tree indexes are built for: an index on the join column supports fast equality lookups directly. A non-equi (range) join can't use a simple equality lookup the same way; the optimizer typically has to do more work, for example scanning or index-range-scanning the smaller side of the comparison per row of the larger side, which scales worse than an equi-join as both tables grow. For a small, mostly-static lookup table like pricing tiers this rarely matters in practice, but the same non-equi pattern applied to two large, fast-growing tables (matching every event to the marketing campaign whose date range it falls within, say) is exactly where you'd want to think carefully about indexing strategy for the range columns, which is its own deeper topic.

Direct answer. INTERSECT returns only the rows that appear in BOTH result sets. EXCEPT (MINUS in Oracle) returns the rows that appear in the FIRST result set but not the second. Both compare whole rows, need the same number of columns with compatible types on each side, and both dedup their output.

Structured elaboration. Think of them as set arithmetic over two same-shaped result sets rather than as joins: there's no join key to specify, the entire row IS the comparison unit. That makes them a natural fit for comparing two snapshots or two populations directly, without writing an explicit join condition.

Worked example. customers_2023(customer_id): 1, 2, 3. customers_2024(customer_id): 2, 3, 4.

-- customers present in BOTH years (returning customers)
SELECT customer_id FROM customers_2023
INTERSECT
SELECT customer_id FROM customers_2024;
-- returns 2, 3

-- customers present in 2023 but not 2024 (lost customers)
SELECT customer_id FROM customers_2023
EXCEPT
SELECT customer_id FROM customers_2024;
-- returns 1

Trade-offs and pitfalls. Both operations dedup by default (like UNION, not UNION ALL), so if you need to know HOW MANY TIMES a row appeared rather than just whether it appeared, INTERSECT/EXCEPT are the wrong tool and you need an explicit join or GROUP BY instead. NULLs in the compared columns are handled specially: unlike an ordinary equality comparison, most engines treat two NULLs in the same position as equal for the purposes of this row comparison, which is the opposite of how NULL behaves in a join predicate, and is a common source of confusion when you've internalized "NULL never equals NULL" from working with joins.