Chapter 6 — Further Reading

Joins reward practice more than reading. Do the drills, then consult these when a specific join puzzles you.

Official reference (everyone)

PostgreSQL Docs: "Queries → Joined Tables." The authoritative description of INNER, LEFT/RIGHT/FULL OUTER, CROSS, ON, USING, and natural joins. https://www.postgresql.org/docs/current/queries-table-expressions.html
PostgreSQL Docs: "Table Expressions." How FROM builds the row source that joins operate on — useful background for lateral joins and subqueries in FROM (Chapter 9).

"Visual representation of SQL joins" (the Venn-diagram explainers). A helpful mental model for INNER/LEFT/RIGHT/FULL — with the caveat the chapter raised: Venn diagrams describe which rows are kept, not row multiplication (fan-out), so don't over-trust them for one-to-many joins.
Julia Evans' "SQL queries don't start with SELECT" (and similar). A clear, friendly explanation of logical evaluation order that makes joins + WHERE + GROUP BY click.

Articles on the "fan trap" / "join fan-out" / "chasm trap." The formal names for Case Study 1. BI tool docs (Looker, Tableau, dbt) discuss these extensively because they bite every analytics team.
dbt and analytics-engineering blogs on "join grain" and "primary key tests." Practical discipline for keeping joins honest at scale — testing that a join key is unique before you trust the result.

Ramakrishnan & Gehrke / Silberschatz — the join chapters. Outer joins and the relational-algebra treatment of joins (theta, equi, natural).
Join algorithms: nested loop, hash join, merge join. Read a short overview now; you'll study how the optimizer chooses among them in Chapter 24. Understanding the algorithms explains why indexing join columns matters so much.
Lateral joins (JOIN LATERAL). PostgreSQL's powerful tool for "for each row of A, run this subquery." Save it for after Chapter 9, but know it exists.

Appendix C — SQL Quick Reference: join syntax at a glance.
Appendix I — SQL Cookbook: ready-made recipes for anti-joins, "top N per group," and "include the zeros."

Build the six-table query yourself, one join at a time, checking the row count after each addition. Watch where fan-out appears.
Cause fan-out on purpose: join orders to order_items and SUM an order-level column; compare to the join-free baseline. Then fix it by pre-aggregating.
Flip INNER ↔ LEFT on the "average per customer" query and watch the number (and the customer count) change. Internalize that a join type is a decision about meaning, not just syntax.

Next: Chapter 7 — Aggregation: GROUP BY, HAVING, and turning rows into summaries.