What You'll Master Here
model entities, then query. NoSQL: list the queries, then model the data to serve them in one cheap operation.
Every chapter so far assumed a relational database: model the entities, normalize, then write whatever query you need. NoSQL stores take away the join, and with it the ability to rescue a bad shape with a clever query — so the order of work inverts. The query list is written first, and the schema is whatever answers it.
Put the five design moves below into NoSQL order, then read the relational order beside them. The rest of the chapter is those moves in detail: the embed-vs-reference call in documents, partition and sort keys, single-table item collections, the indexes that rescue a pattern you did not foresee, Cassandra's hard limits, and choosing the store at all.
Relational: model entities, then query. NoSQL: list the queries, then model the data to serve them in one cheap operation.
NoSQL stores are fast and scalable only when the data is modeled around their access patterns. A relational-style model on NoSQL gives you the worst of both: no joins to fix it, and a shape that fights every query.
- access pattern
- A specific read or write the application must perform (e.g. "get a hiker's last 20 ascents, newest first").
- denormalization
- Duplicating or nesting data so a query is served without joins.
- partition key
- The attribute that decides which physical partition a record lives on.
- single-table design
- Storing multiple entity types in one table, co-located by access pattern.
- 1Sketch the entities and how they relate
- 2Normalise them into tables
- 3Declare keys and constraints
- 4Index whatever turns out to be slow
- 5Write queries last — the optimiser plans them
Designing a NoSQL schema the way you would a relational one (normalized entities). Every screen needs multiple round trips with no joins to help; performance and ergonomics both suffer.
Write down the access patterns before any schema.
Shape data so each pattern is one cheap operation.
Accept duplication when it removes a join NoSQL cannot do.
In NoSQL the query is the spec and the schema is the implementation. You denormalize on purpose so the database does the least possible work per request.
The studio starts from entities and relationships. Forcing single-table items onto an ER canvas teaches the wrong mental model; the native artifact here is the access-pattern list, which you build in the next topic.
NoSQL modeling is access-pattern-first: list the queries, then design data (often denormalized) so each query is one cheap operation, the reverse of relational modeling.