← DDIA

Chapter 02 · Data Models

Data Models & Query Languages

Your objects don't fit in tables. That mismatch shaped fifty years of databases.

Same résumé, three ways to store it. The right one depends on how connected the data is.

Three acts: 1. shape 2. many-to-many 3. pick

The many-to-many problem

Same edit, two data models.

DOCUMENT 0 writes
"user": "User 1",
"company": "Aetna"
"user": "User 2",
"company": "Aetna"
"user": "User 3",
"company": "Aetna"
RELATIONAL 0 write
companies
id42 name"Aetna"
positions
user1 company_id42 "Aetna"
user2 company_id42 "Aetna"
user3 company_id42 "Aetna"

Three writes vs one. Documents still win on read locality: one lookup returns the whole record.

Takeaway

The shape of your relationships picks the database. Not hype.

Pick by shape.

01

Document

one-to-many, self-contained.

PICK WHEN the record has clear boundaries; you read it as one unit.
STRUGGLES AT joins, shared entities, many-to-many.
EXAMPLES MongoDB, DynamoDB, CouchDB.
02

Relational

many-to-many with shared entities.

PICK WHEN entities are referenced from many places; you edit them in one place.
STRUGGLES AT deep, variable graph traversals; free-form nested docs.
EXAMPLES Postgres, MySQL, SQL Server.
03

Graph

highly connected, variable depth.

PICK WHEN the interesting query is a traversal: friends of friends, dependency chains.
STRUGGLES AT sheer volume of flat, tabular data.
EXAMPLES Neo4j, Datomic, JanusGraph.

Same résumé, three physical shapes. Pick by how connected your data is.