A dashboard reads. An operation writes. When you model for the dashboard, you optimise for SELECT. When you model for the operation, you optimise for INSERT, UPDATE, DELETE — and the constraints that keep the business rules true.
The write path is the contract
Every write is a business event: an order placed, a shipment received, an invoice matched. The schema must make illegal states unrepresentable. Foreign keys, check constraints, unique indexes, triggers — these are not "database features", they are the encoded rules of your operation.
Common mistakes
- Storing derived data instead of computing it (leads to drift).
- Soft deletes without a clear policy (leads to ghost records).
- Polymorphic associations without a discriminant (leads to query chaos).
- No audit trail on financial or compliance-relevant tables.
How we model
We start with the workflow, not the ER diagram. Every state transition in the workflow becomes a constraint or a transition table in the model. The read models (views, materialised views, API shapes) are derived afterwards — they are disposable, the write model is not.