Normalization

Storing each fact in exactly one place and pointing at it from everywhere else, so an update only has to happen once.

stop copy-pasting the same data everywhereone source of truth per fieldsplitting data into separate tablesdatabase normalisationnormalizing the databasethird normal form3NFget rid of the duplicated columns

See it

Live demo coming soon

What it is

Normalization is the discipline of storing every fact exactly once and referencing it from everywhere else. Instead of writing the customer's address into all 400 of their order rows, you keep one customers row and put a foreign key on each order. The formal ladder comes from E. F. Codd: first normal form (no repeating groups or comma-separated lists in a column), second (no column depending on only part of a composite key), third (no column depending on another non-key column). In practice, 'normalized' in conversation means roughly 3NF.

The payoff is that updates are cheap and honest. Change the address in one place and every query sees it. Duplication creates update anomalies: you fix nine copies, miss the tenth, and now the data contradicts itself with no way to tell which row is right. Reach for it by default in any write-heavy application database.

Two things people get wrong. Normalization buys correctness and pays in joins, so a genuinely read-heavy path may deserve deliberate denormalization later, after you measure. And a copied value is not always a normalization failure: the price on an invoice, the name on a signed contract, the shipping address as it was that day are point-in-time snapshots. Those belong on the row, because pointing at the live record would silently rewrite history.

Ask AI for it

Normalize this schema to third normal form. For each table, identify the primary key, then pull out every group of columns that repeats across rows or depends on something other than the key into its own table linked by a foreign key. Split any comma-separated or numbered columns (tag1, tag2, tag3) into a child table, and model many-to-many relationships through a junction table with a composite unique constraint. Add NOT NULL and foreign key constraints with explicit ON DELETE behavior, and index every foreign key column. Deliberately keep point-in-time snapshot values (line item price, address at time of shipping) copied on the row, with a comment saying why. Output the migration SQL plus a short before/after table list explaining what moved where.

You might have meant

denormalizationforeign keyprimary keyjoinone to many relationship

Go deeper