The Data Model Is the Decision

Software is built by hiding things. The application hides the database, the database hides the filesystem, the filesystem hides the block device, the block device hides magnetism or trapped charge. Each layer offers a clean model and refuses to discuss what is underneath.

That works remarkably well — until one layer’s model does not fit what you are trying to say. Then everything above it becomes an elaborate apology.

The stack, concretely

A single fact — Ada works at Acme since 2021 — passes through several models on its way to a disk:

1. The real world. People, employers, the fuzzy concept of “works at” which covers full-time, contract, secondment and three other cases.
2. The application model. Objects, structs, records. Employment { person, company, startedAt }. Already a decision: is employment a thing, or a field on a person?
3. The storage model. Rows in tables, or a document, or a graph edge. Now you have committed to how it can be queried.
4. Bytes. Pages, index entries, log records — Module 3’s territory.

Each translation loses something. The interesting losses happen between steps 2 and 3, and that is what this module is about.

Why this decision outranks the others

You can replace a web framework in a quarter. You can rewrite a service in a sprint if you must. You do not casually change how ten million rows are shaped, because every query, every index, every report, and every integration that ever touched them assumes the old shape.

So the data model is the decision with the longest half-life in the project — and it is routinely made in the first week, by whoever set up the repository, before anybody understands the domain.

The question that actually chooses

Not “SQL or NoSQL.” Not “which database is fastest.” The question is about the shape of your relationships, and it has three parts:

How does the data relate to itself? Is it a tree — a thing with parts that belong to it and nothing else? A web — things that reference each other in many directions? Or a list of independent records that barely touch?

Which way do the queries run? Do you fetch one root object and everything under it? Or do you start from a leaf and ask which roots reference it? The second direction is where a wrong model starts to hurt.

What changes, and how often? Data that is written once and read forever tolerates duplication. Data that is edited constantly punishes it, because every copy is a chance to disagree.

A worked example of the loss

Suppose you model a résumé as a document, because a résumé really is a tree — one person, their jobs, their schools, all belonging to that person alone:

{
  "name": "Ada",
  "positions": [
    { "company": "Acme", "title": "Engineer", "from": 2021 }
  ]
}

This is a good fit. Fetching a résumé is one read. Nothing dangles.

Now the product team asks: show me everyone who has worked at Acme.

Suddenly “Acme” is not a leaf on Ada’s tree — it is a shared entity that many trees point at. The string "Acme" appears in ten thousand documents, spelled nine different ways, and the question you have been asked runs in the direction your model cannot follow.

That does not mean the document model was wrong. It means it encoded an assumption — companies are attributes of people, not entities in their own right — and that assumption has now expired.

What to take away

The data model is where your assumptions about the domain get written down in a form that is expensive to change. Make the choice deliberately, from the shape of the relationships and the direction of the queries — and expect to discover one direction you did not plan for, because everybody does.