When do you normalise or denormalise data?

Direct answer

What a strong answer covers

How it works

Normalisation removes redundancy so each fact is stored once: a customer’s address lives in one row, and changing it cannot leave a stale copy somewhere else. That is the right default for transactional data because it prevents update anomalies and keeps invariants enforceable with constraints. Denormalisation copies or precomputes data to make specific reads cheaper, and it is a deliberate trade: every copy needs an owner, a synchronisation path, and a tolerance for lag. It belongs in reporting schemas, caches, and read models, or in a hot path where a measured join cost justifies it, never as the starting shape of the source of truth.

Example

An order system stores customer details once and joins them on read; a reporting warehouse keeps a denormalised orders table with customer name and segment copied in, rebuilt nightly from the normalised source. When the checkout page’s join across five tables measured 80 ms, a materialised order summary with a trigger-maintained total was added for that page only, documented as derived data with its refresh rule.

Common mistakes

• Denormalising the transactional schema up front for imagined performance.
• Copying a field into three tables with no process to keep them in sync.
• Normalising a reporting schema so every dashboard needs a twelve-table join.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.