Chapter 4: Querying & Filtering
Before any dashboard can render, before any report can be emailed, before any machine-learning pipeline can train, someone has to retrieve the right rows from a database. That retrieval is a SQL query, and every query, no matter how sophisticated, is assembled from a small set of building blocks: choosing which columns to return, filtering rows down to only the relevant ones, sorting the results into a meaningful order, and capping how many rows come back.
Chapter 5: Joins
A relational database splits information across tables on purpose. products doesn't repeat the category name on every row; it stores a category_id and points to categories for the rest. This keeps data small and consistent: rename a category once, and every product referencing it is automatically up to date.
Chapter 6: Views
The customer worklist query that closed Chapter 5, using three joins, a status filter, and a sort, is exactly the kind of query that gets written once, works well, and then gets copy-pasted into five other reports over the following year. Each copy drifts slightly. One person adds a column, another fixes a typo in only their version, and six months later nobody is confident the five reports agree with each other. A view solves this by giving a query a name.