What It Actually Means
Most business systems use a relational database, where data lives in tables with defined relationships between them. Customers have orders, orders have lines, lines refer to products. The structure enforces those relationships, which is what stops the data quietly becoming nonsense.
Why This Is The Part That Matters
Of everything in a software project, the database is the part with the longest life and the highest cost of getting wrong.
Interfaces get redesigned. Frameworks get replaced. Whole applications get rewritten, and it is expensive rather than catastrophic. The data outlives all of it, and every one of those rewrites has to work with whatever structure was chosen at the beginning.
A well-structured database supports questions nobody thought to ask when it was built. A badly structured one makes ordinary reporting difficult forever, and fixing it means migrating live data, which is the riskiest work in software.
That is why the database design conversation deserves your attention even though it is the least visible part of a project. It is the decision you will live with longest.
What Good Structure Looks Like
You do not need to read a schema. A few signs are visible from the outside.
Each fact stored once. A customer’s address in one place, referenced where needed. When the same information is duplicated across tables, versions drift apart and no one knows which is right.
Real relationships. A record referring to another should be enforced, so an order cannot exist for a customer who does not.
Sensible types. Dates stored as dates, money as an exact numeric type rather than as decimals prone to rounding, references as identifiers rather than as names.
History where it matters. Anything that changes and needs to be justified later, prices, statuses, permissions, should keep its previous values rather than overwriting them.
The Warning Signs
Ordinary questions that require a developer. If asking how many customers ordered twice last quarter needs a bespoke query every time, the structure is fighting you.
Reports that disagree. Usually the same information stored twice and updated in one place.
Fields used for something other than their name, a spare column repurposed for a different meaning, which is the beginning of a structure nobody can reason about.
Everything stored as text, so dates cannot be compared and figures cannot be summed without conversion.
What To Ask
- Can we see the data model? A supplier should be able to explain it in plain terms. If they cannot, that is informative.
- What questions will be hard to answer later? Every design makes some things easy and others hard. Knowing which is worth having in advance.
- How do we get all our data out? The most important question, and the one that decides whether you are ever trapped.
- What is kept as history rather than overwritten? Ask specifically about prices, statuses and permissions.
- Who else can read this? Access to the database bypasses every rule the application enforces.
On Choosing One
For the overwhelming majority of business systems, a mature relational database such as PostgreSQL or MySQL is the right answer, and the choice between them matters far less than how it is used.
The alternatives, NoSQL and similar, solve genuine problems that most businesses do not have. Choosing one for a system that is fundamentally about related records tends to move the work of maintaining consistency out of the database and into application code, where it is done less reliably and by hand.
More terms are in the glossary.
