The data model is the foundation of every system.
Screens can be redesigned in days. The structure of a system's data shapes everything it can do, and changing it after the fact is slow and risky. That's why, on every system we build, the data model is designed and agreed before the interface.
What is a data model?
A data model is the structure that describes what information a system stores and how those pieces relate — customers and their accounts, orders and their items, products and their locations. In a relational database, it's expressed as tables and the relationships between them.
A good data model reflects how the business actually works: one customer with several sites, one order with several deliveries, one product stocked in several places.
Signs of a poor data model
- The same information stored in several places, and drifting apart
- Reports that need manual adjustment to be correct
- New products, locations or rules requiring workarounds
- “We can't track that, the system doesn't allow it”
- Slow screens as data grows
How we design data
- Model the business, not the screens. Tables reflect real-world things and relationships.
- Store each fact once. Everything else references it.
- Record changes as transactions. Inventory and balances are explained by their history, not overwritten.
- Constrain at the database. Rules enforced by the database, not only the interface.
- Index for how data is used. Frequent searches and reports stay fast as data grows.
- Keep an audit trail. Important changes record who and when.
Data migration
Moving data from spreadsheets or old systems is often the riskiest part of a project:
- 1.Inventory existing sources
- 2.Clean duplicates and inconsistencies
- 3.Map old fields to the new model
- 4.Trial-migrate and check figures
- 5.Final migration at go-live
- 6.Reconcile against the old records during parallel running
Protecting the data
Backups, access control, encrypted connections and least-privilege permissions for integrations.