Choose a schema from the questions the data will be asked rather than from the shape it arrives in, well enough to justify every column, to know which duplication is a mistake and which is a decision, and to change it later without downtime

Designing a Table to Live With

A schema is the one decision that is expensive to reverse. This course derives normal form from first principles, then covers when to break it on purpose, how to model time, and how to migrate a table people are using.

8 lessons, written and corrected before you arrived. Reading them here needs no account. The first reads the whole way through; the others open and then stop, because a page nobody owns cannot tell who is reading it. Starting the course gives you your own copy, where every idea has problems standing under it and you can ask about any sentence.

Start reading

01Say Out Loud What One Row Is ClaimingA table is a sentence with holes in it and a row fills the holes. Write that sentence down and most arguments about table boundaries answer themselves.
02Seventy-Eight Copies and No Tiebreakeropening onlyThree failures follow from storing one fact twice, and all three are derivable rather than memorable. Normal form is the name for the repair, not a rule to obey.
03The Email Address Was Reused by the New Employeeopening onlyA key is the smallest set of blanks that makes the claim unique. Choosing it badly is the one schema mistake that spreads into every other table you will ever write.
04There Is No Column That Can Hold a Listopening onlyTwo of the three relationship shapes are a column. The third cannot be, and the reason is worth deriving rather than memorising, because it tells you what the extra table is.
05The Query Returned Nothing and the Query Was Correctopening onlyAn empty cell can mean three different things, the database treats all three identically, and the result is a comparison that is neither true nor false and an average over a changing denominator.
06Copy the Value Only If You Are Also Building the Thing That Repairs Itopening onlyDeliberate duplication is a trade: reads get cheaper, writes get harder, and something has to keep the copy true. Here is the arithmetic and the two cases that are not really duplication.
07The Report Was Right in March and Is Wrong Nowopening onlyAn update destroys the past. Keeping history means storing when each value was true, and the harder half is separating when something happened from when you found out.
08For Twenty Minutes, Both Versions Have to Be Rightopening onlyA deploy is gradual, so old and new code run at once against one schema. Every safe migration is the same six steps, and a few changes have no safe sequence at all.