The Data Model Decides Everything After It

Model the business, not the screen

Models designed around the first interface tend to need restructuring as soon as the second one arrives. Model the entities and relationships the business actually has.

The question is not what fields the form needs. It is what a customer, an order or a job actually is in this business, including the awkward cases.

Constraints belong in the database

• Unique constraints where duplicates must not exist
• Foreign keys with the right deletion behaviour, decided rather than defaulted
• Check constraints for values with defined ranges
• Not-null where a value is genuinely required
• Indexes on what you will filter and join by

Application-level validation can be bypassed by a management command, a data import or a bug. Database constraints cannot.

Audit fields on anything that matters

1. Created and modified timestamps on every model
2. Created by and modified by where accountability matters
3. Soft deletion rather than hard deletion for business records
4. A history table for anything disputed or regulated

Adding these later means backfilling data that does not exist. Adding them at the start costs nothing.

Choices and reference data

Free text where a defined set belongs is the most common cause of data quality problems in business systems.

Migrations are permanent

Every schema change is a migration that will be applied to production. Review them like code, test them on a production-sized copy, and never edit one after it has been applied anywhere.

Backwards-compatible changes — adding before using, removing later — make rollback practical, which is worth the discipline.

Frequently asked questions