8. SQL vs NoSQL
1
The picture to keep in your head2
8.1 What are tables, rows and keys?3
8.2 What does ACID mean?4
8.3 What is normalisation, and what are joins?5
8.4 What kinds of NoSQL databases are there?6
8.5 What's the difference between schema-on-write and schema-on-read?7
8.6 Why does NoSQL often duplicate data and avoid joins?8
8.7 How do you choose between SQL and NoSQL?9
Memory card and where the analogy breaks10
Practice: five levels11
Interview questions12
Solutions13
Sources14
Code lab8. SQL vs NoSQL
Memory card and where the analogy breaks
3 min read+10 XP
The memory card (tear this page out)
| # | Question | Memory code |
|---|---|---|
| 8.1 | Tables, rows, keys? | One table per thing, one row per item, keys for the links |
| 8.2 | ACID? | All or nothing, rules always hold, no peeking, written in ink |
| 8.3 | Normalisation and joins? | Write it once, link it everywhere, join when you read |
| 8.4 | NoSQL families? | Hook, folder, logbook, pinboard |
| 8.5 | Schema-on-write vs read? | Check at the door, or check when you open the folder |
| 8.6 | Denormalisation? | Store it the way you read it, and pay on every update |
| 8.7 | How to choose? | Money in the ledger, stories in folders; when in doubt, ledger |
The whole chapter in one line: Link what must stay correct, copy what must be read fast, and choose by how you'll ask.
Where the analogy breaks
- A ledger is slow to search by hand. A relational database isn't: with the right indexes, joins over millions of rows take milliseconds (Chapter 9).
- A folder cabinet sits in one room. NoSQL databases are usually spread across many machines, which is exactly why they avoid joins.
- "SQL vs NoSQL" sounds like two camps. In practice it's a toolbox, and one system often uses several databases, each for the job it fits.
Quick check
Five questions on this chapter. Pick an answer, then check it.
quiz