Chapter Four · Reassembling Answers
Combining Tables — JOINs
Chapter 2 taught you to split the Marquee's data across four tables and point with ids; the price of that virtue is that every interesting answer now lives in two or three tables at once. This chapter teaches the read-side half of the bargain: JOIN, the operation that follows the pointers and turns ids back into sentences. Five topics take you from why JOINs exist at all to four-table queries you can read like a story — and, at the end, queries nested inside other queries.
Here is a row from the bookings table you built in Chapter 2. It says customer_id 214, screening_id 88, seat G7 — perfectly correct, and unreadable. The name lives in customers, the film and the time live in screenings and films, and what Lora actually wants to see is one plain line: "Anna · Night Bus · Friday 20:00 · G7". Storing each fact exactly once was the right design; now you learn the operation that pays for it at read time.
The chapter builds in careful steps. First the why: what problem JOIN solves and why splitting the data was still worth it. Then INNER JOIN, the workhorse that combines two tables on a matching rule. Then LEFT JOIN, which makes absence visible — the customers who never booked, the films nobody watched. Then the technique for chaining three and four tables without fear. And finally subqueries: whole queries tucked inside other queries, because every query returns a table and tables feed queries.