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
- Created and modified timestamps on every model
- Created by and modified by where accountability matters
- Soft deletion rather than hard deletion for business records
- 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
| Approach | Suits |
|---|---|
| Choices on the field | Fixed, rarely changing, code-level meaning |
| A related model | Business-editable, extensible |
| Free text | Almost never — it becomes inconsistent |
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.