8.6 Why does NoSQL often duplicate data and avoid joins?

In the office: The folder for order 901 contains a copy of the book titles and author names, so the clerk reads one folder and is done. The price: when an author changes their name, every folder with the old name is now out of date.

In the system: Denormalisation means storing copies of data where it's read, so a common read needs one lookup instead of a join.

Figure: normalised data is stored once and joined; denormalised data is copied in so one read gets everything.

Why NoSQL leans this way: most NoSQL databases are built to split data across many machines by key (Chapter 15). A join between data on different machines is slow and complicated, so many NoSQL databases offer limited joins or none, and you design around that: put together the data that's read together.

The cost:

• Updates fan out: renaming an author means updating every document that holds a copy. In the chapter's code, one SQL row vs 10,000 documents.
• Copies drift: if one of those updates fails, documents disagree.
• More storage.

Some copies are correct, even in SQL. An order should keep the price paid at the time, even if the book's price changes later. That's not duplication, it's a snapshot of history, which is why order_items has its own price column.

Memory code: "Store it the way you read it, and pay on every update."

---