Normalization Without Cargo Culting

The starting point

Database normalization can be taught as a list of normal forms, but the practical idea is easier: do not store the same fact in multiple independent places unless you have a deliberate reason to do so. If an article category name is copied into every article row, changing the category name creates a synchronization problem. A separate category entity gives the fact one authoritative home.

The enemy is contradictory state

Duplication is not automatically wrong. Sometimes a system intentionally stores derived or denormalized data because reading it repeatedly is expensive. The danger appears when two copies are treated as equally authoritative and can diverge.

Normalization therefore starts with ownership. Ask where a fact belongs and which other records should reference it. Once that is clear, normalization becomes a way of expressing the ownership structure rather than a checklist to satisfy for its own sake.

Denormalization should have a reason

If a read-heavy system repeatedly needs a costly aggregation, storing a derived value can be reasonable. But the tradeoff should be explicit: writes become more complicated because the derived representation has to stay correct.

For a portfolio application, premature denormalization would add complexity without solving a real bottleneck. A straightforward relational model is easier to understand, migrate, and debug while the dataset is small.