Five mistakes teams make with database schema design

There is no clever trick in this one, just a handful of decisions worth making deliberately. These are the ones we run into repeatedly when we audit database schema design.

The question is rarely whether something can be built, but what it costs to keep running afterwards. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Warning signs

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Schema mistakes get more expensive every month they survive
• Model the real relationships, not the current screens
• Never checking whether the fix actually worked

Constraints in the database beat validation in five places. The cost of getting this wrong is rarely visible on the day it happens. If two people in the business would answer this differently, that gap is the actual problem.

Making it stick

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
• Constraints in the database beat validation in five places — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.