Databases Model Reality
What happens the first time the real world turns out to be messier than your table design assumed?
The idea
A database schema turns real-world entities and relationships into structured records.
In the real world
An order links a customer, products, payment, and status.
Going deeper
A schema is a set of claims about the world: that an order has exactly one customer, that an address belongs to one person, that a name fits in 60 characters. Each is true until it is not, and every query, report and integration is written assuming it holds.
The cost asymmetry is what makes this worth care. Adding a column is cheap. Changing a one-to-one relationship into one-to-many touches every join, every form and every export that ever assumed otherwise. When modelling, the question worth asking is not what is true now but which of these claims is most likely to stop being true.
Where it stops applying
Over-modelling for hypothetical flexibility has its own cost: a schema built for every conceivable case is slower to query and harder to reason about. Model the relationships you can name a plausible reason for, not all of them.
Why it matters
Schema choices are the hardest thing to reverse later, because every query, report and integration is written against them.
Try this today
Name the entities and relationships before choosing tables.
Test yourself
Your orders table has a single customer_id column. A client asks to split one order across two billing entities. Why is this a schema problem rather than a feature request?
Show the answer
A single column can only express one customer per order. To honour the request you either corrupt the data with a placeholder customer or change the relationship itself and everything that reads it. The model, not the request, is what is refusing.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.