Denormalisation is a Governance Problem
Denormalisation is usually framed as a technical decision.
- performance
- query simplicity
- reporting convenience
But in operational systems, it has a second effect.
It changes where truth lives.
The hidden shift
When a value is duplicated:
- customer name
- port description
- calculated totals
you are no longer just optimising access.
You are creating:
- a second copy of reality
That introduces a question:
which one is correct?
Where this becomes visible
Initially, it works well.
- faster queries
- simpler forms
- easier reporting
Then, over time:
- the source value changes
- the cached value doesn’t
- users start trusting one over the other
At that point, it is no longer a performance issue.
It is a trust issue.
Why this is a governance problem
Because the system now needs to decide:
- when the value should be refreshed
- whether it can be edited
- what happens if it drifts
- who is responsible for correcting it
Those are not database concerns.
They are control concerns.
Typical patterns (often implicit)
In many systems, these rules exist but are hidden:
- refresh on update (sometimes)
- manual correction (sometimes allowed)
- no clear audit trail
- no visibility of drift
The behaviour is inconsistent.
The intent is unclear.
Making it explicit
A more useful approach is to treat denormalised fields as governed elements.
For each one, define:
- source of truth
- refresh trigger
- editability
- override conditions
- reconciliation behaviour
For example:
- always refreshed on commit
- never editable
- or editable only with audit
- or allowed to drift within a tolerance
Why this matters more in real systems
In controlled environments, normalisation works.
In operational systems:
- performance matters
- reporting matters
- users expect visible values
So denormalisation is often unavoidable.
The problem is not that it exists.
It’s that it’s rarely managed deliberately.
Where this connects back
Once denormalisation is treated as governance:
- it can be checked at commit
- it can be audited
- it can be explained
Instead of being:
- hidden
- inconsistent
- and occasionally wrong
Closing thought
Denormalisation is not just a data design choice.
It is a decision about:
- how truth is represented
- how it is maintained
- and how much drift is acceptable
Those are governance questions.
Treating them that way makes the system more predictable.