Storing facts once
Normalization organizes data so each fact lives in exactly one place. A user name sits in one row, and every order points to that user by id. This keeps writes simple and prevents contradictions because there is a single source of truth.
The cost is that reads must join many tables to assemble a view, and joins get expensive at scale.
Copying facts on purpose
Denormalization deliberately duplicates data so a read can be served from one place without joins. You might store the user name directly on each order row.
- Reads become fast and simple.
- Writes become harder because a name change must update many copies.
- Copies can drift out of sync if an update is missed.
How to choose
- If the workload is write heavy or correctness critical, prefer normalization.
- If the workload is read heavy and reads dominate cost, denormalize the hot paths.
- A common pattern keeps a normalized source of truth and builds denormalized read models that are rebuilt from it.
Denormalize as an optimization you can justify, not as a default.
Key idea
Normalization stores each fact once for safe writes while denormalization copies facts for fast reads, trading write effort for read speed.