The One-Big-Table Problem

Every beginner builds it once: the one big table that knows everything. It starts innocently. You have a students table, and you'd like to record each student's class too — the class name, the teacher, the room. Why not add columns?

students
id | name   | class | teacher    | room
---+--------+-------+------------+-----
1  | Sara   | Music | Ms. Danso  | 12
2  | Marcus | Art   | Mr. Petrov | 30
3  | Amara  | Music | Ms. Danso  | 12
4  | Tefera | Music | Ms. Danso  | 12

It works. It prints nicely. And it has already started to rot.

Duplication: the same fact, over and over

Look at what the Music class costs you. Its teacher and room are written out on every Music student's row — three copies already, thirty by the end of enrollment week. That's data duplication: one fact about the world ("Music happens in room 12 with Ms. Danso") stored as many separate copies, one per row that happens to mention it.

In library terms: every member's card carries a hand-copied description of every book they've borrowed. Hand-copying is exactly how facts pick up errors — one card says room 12, another says room 21, and both were typed by tired humans. With duplication, it's not a question of whether the copies disagree. It's when.

The update anomaly: fixing a fact and missing its copies

Now the school moves Music to room 15. In the one big table, that fact lives in thirty places. Whoever updates it must find and change every copy — and the day they miss one, something genuinely bad happens:

1  | Sara   | Music | Ms. Danso  | 15
3  | Amara  | Music | Ms. Danso  | 15
4  | Tefera | Music | Ms. Danso  | 12   <- missed

The database now confidently states two different rooms for one class. This failure has a name — an update anomaly — and the cruel part is that the database can't warn you. Every individual row looks fine; only the disagreement between rows is wrong, and nothing checks that. Which row would a newcomer trust? There is no longer a right answer inside the data. Once a database contradicts itself, every answer it gives arrives with an invisible asterisk.

Deleting has a sibling anomaly, quieter but crueler: if the last Music student leaves and their row is deleted, the class itself — its teacher, its room — vanishes from the database entirely. The fact was only ever stored as a passenger on someone else's card.

The diagnosis

Notice what the two anomalies share: this table is holding two kinds of thing — students and classes — which breaks the one-drawer-one-kind rule from earlier, and it stores a fact once per row when the world holds that fact once, period. A fact should live in exactly one place, so changing it means changing one card, and no two cards can ever disagree.

The cure is not discipline. Nobody out-focuses thirty copies forever. The cure is structure: give classes their own drawer, and let student cards merely point at it — using precisely the IDs you met last lesson. That pointing trick is the next lesson, and it is the moment databases go from "tidy spreadsheets" to something genuinely powerful.