Data Modelling
Part of No-code data modelling
Avoiding repeated data in several no-code tables
Find conflicting copies of a fact, give current values one owner and distinguish linked displays from historical snapshots.
When the same current fact is editable in several tables, give it one authoritative home and display it elsewhere through a relationship where the builder supports that.
Keep a separate copy when it has a different purpose, such as recording what was known when a transaction occurred.
Key Principles for Data Integrity in No-Code Systems
- Single Source of Truth
- One authoritative home for editable facts
- Historical Snapshots
- Retain labelled values when tracking past states
- Relationship-Based Display
- Show data via links instead of duplication
- Change with Caution
- Test impacts before replacing fields
Find copies that can disagree
Imagine Clients, Projects and Invoices tables. If a client's current contact number is typed into all three, a change can leave three answers to “what number should we call now?”. Keep the current number on the client record and link the projects and invoices to that client. A project screen can then display it without a second update.
An invoice address recorded at issue may serve another purpose. If the business must show which address was used on that invoice, retain it as a labelled historical value. Updating the client's current address should not quietly change the meaning of the earlier document. Agree which historical values matter; do not snapshot every field by default.
Give each repeated value a reason
| Value | Question to ask | Likely treatment |
|---|---|---|
| Current client contact detail | Which record owns updates? | Maintain it on the client; display it through the relationship. |
| Invoice address at issue | Must the earlier value remain explainable? | Keep a labelled snapshot if required. |
| Client reference on a project | Which client does this project belong to? | Keep the reference; it connects the records. |
| Calculated project total | Must it reflect current related rows or a past agreed amount? | Calculate it where suitable; store an agreed historical amount separately if needed. |
A reference to a related row is different from several editable copies of an address. A link between records does not by itself decide whether a historical value should be retained.
Change an existing field carefully
For one candidate field, identify its authoritative record. Compare the copies by record ID and relationship, not by name alone. Ask the data owner to resolve disagreements before replacing values with linked displays; a mismatch may be a legitimate older value or a different client.
List the screens, reports and automations that read the field. Test a proposed replacement against fictional records with a current value, a changed value and a missing or incorrect link. Preserve any history the business needs before removing an old field.
