The real cost of ignoring database schema design
We end up explaining this on discovery calls often enough that it deserved writing down. Nobody bills you for neglecting database schema design. The cost shows up somewhere else.
Code gets read far more often than it gets written, and usually by someone with less context than the author had. It is the sort of thing that looks like polish right up until it costs you an enquiry.
Where the cost lands
- Time spent on work that should not have been necessary
- Enquiries that quietly never arrive
- Schema mistakes get more expensive every month they survive
- Rework, once the problem is finally visible
Model the real relationships, not the current screens. Small and consistent beats large and occasional here. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.
Where to go from here
Constraints in the database beat validation in five places. The teams that handle this well are rarely the ones with the biggest budgets. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.
What this looks like day to day
Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about database schema design before you move on:
- Someone can say what the current setup is without going to look
- Model the real relationships, not the current screens — and you know whether that is true here
- There is a way to tell whether the last change to this helped
Pick the one that would hurt most if it failed, and start there.