Overview
In this part, the course shifts from adding new features to strengthening the work already done. Earlier parts asked how to model data, how to create schemas, how to write queries, and how to summarize information. This part asks three different kinds of questions:
- when several writes belong together, how do we make sure they all happen or none of them do?
- when the schema has been growing across several parts, how do we recognize and repair quality problems before they spread?
- when the queries start to feel slow or awkward, how do we identify the real cause and apply the right fix?
These three themes — correctness during multi-step work, schema quality, and performance — are the substance of this part.
The structure of this part is as follows:
- Transactions and Multi-Step Operations explains why some sets of changes belong together and how transactions express that grouping in SQL.
- Concurrency and Isolation shows how simultaneous activity can affect correctness even when each individual transaction looks fine.
- Normalization: From Anomalies to Normal Forms returns to weak schema structure, motivates normalization through update, insert, and delete anomalies, and introduces normal forms as a systematic way to remove the conditions for those failures.
- Denormalization as a Deliberate Trade-Off discusses when storing redundant data is the right exception and how to do it carefully.
- Indexes and Query Plans introduces indexes as the most practical performance tool, alongside
EXPLAINas the way to confirm that the indexes are being used. - Practical Performance and Verifying Improvements shows how to identify common performance problems and confirm that a fix actually helped.
- Project Checkpoint: Building a Study Mode is the first of two project checkpoints in this part. It builds a card-at-a-time study flow on top of the existing study tracker, with the focus on transactional atomicity — making a multi-statement write either fully happen or fully not.
- Project Checkpoint: Moving Cards Between Decks is the second project checkpoint. It builds a move-card feature, with the focus on isolation under concurrent access — making sure two users acting at once cannot corrupt each other’s work, through explicit row locking with
SELECT ... FOR UPDATE.
The two checkpoints exercise the same toolkit on two different features, but each one verifies a different transaction concern in depth: atomicity in the first, concurrency-safe locking in the second. Together they cover the two genuinely distinct kinds of transactional correctness this part introduces.
Recommended Order of Work
A useful rhythm for this part is:
- read the regular chapters in order,
- complete the chapter-level exercises as you go,
- complete the two project checkpoints,
- and finish with the recap quiz and feedback form.
At the end of the part, there is a recap and feedback chapter that briefly summarizes the part and asks for feedback, followed by a short looking forward chapter that points toward where to take this next.