Databases
Normalization
Structuring tables into normal forms so each fact lives in exactly one place, related by foreign keys — which removes update, insert and delete anomalies. It keeps data consistent as it changes. The trade-off is more joins at read time, so read-heavy systems sometimes denormalise deliberately, accepting redundancy for speed.
Purpose
Normalization structures tables so each fact lives in exactly one place, linked by foreign keys — customers in one table, their orders referencing them, not customer names copied onto every order row. It exists to eliminate update, insert and delete anomalies: change a fact once and it is changed everywhere.
When to Use It
It is the right default for transactional systems where data changes — user accounts, orders, inventory — because consistency under change is exactly what it buys. Third normal form (3NF) is the practical target for most schemas.
Trade-offs
Normalised data must be joined back together at read time, and heavy join fan-out can hurt hot read paths. Read-mostly and analytics systems therefore denormalise deliberately — duplicating data for speed and accepting the burden of keeping copies in sync.
Implementation
Give every table a primary key; move repeating groups into child tables; ensure non-key columns depend on the key, the whole key and nothing but the key (3NF). Enforce relationships with foreign-key constraints, and treat any denormalisation as an explicit, documented optimisation with a plan for keeping the copies consistent.