The big idea: A relational database stores data in tables with a fixed schema, and that is the right choice far more often than not.
But when the data has no fixed shape, or must be spread across hundreds of machines, other models trade some of relational's guarantees for what those situations need.
| Type | Stores data as | Suits |
|---|---|---|
| Relational | Tables, fixed schema, joins | Structured data with relationships and transactions |
| Document | Self-contained documents (JSON-like) | Records whose fields vary between rows |
| Key-value | A key and an opaque value | Caches, sessions — lookup by one key, very fast |
| Graph | Nodes and the edges between them | Relationships that are themselves the data |
| Column-family | Columns grouped, not rows | Huge tables where queries read few columns |
Free preview
This is the free notes preview
You're reading the free notes. Aimnova Pro unlocks the full study experience — and you can try it with your first topic free to keep:
- FlashcardsLock in vocabulary and key terms with spaced repetition.
- Practice questionsAnswer exam-style questions and get instant AI marking.
- Mock exams & past-paper vaultSit full mocks and see exactly how examiners award marks.
- Personalised study planA daily plan built around your exam date and weak areas.
Start Studying Free Full access to Aimnova Pro · cancel anytime
Document
- No fixed schema — two records may hold different fields
- A whole record is read in one go, with no joins
- But duplicated data must be updated everywhere it appears
Key-value
- The simplest possible model: give a key, get a value
- Extremely fast, and easy to spread across machines
- You cannot query the value — only fetch it
Graph
- Nodes joined by edges that carry meaning
- "Friends of friends who like X" is one traversal
- In SQL that is a join per level, and it degrades fast
The relational cost that drives this: A relational query answering "friends of friends of friends" needs three joins, and each one multiplies the work. A graph database follows edges directly, so depth costs far less.
Where the relationships are the question, the relational model is doing the wrong kind of work.
Practice with real exam questions
Answer exam-style questions and get AI feedback that shows you exactly what examiners want to see in a full-marks response.
Try Practice FreeYour first topic is free to keep • No credit card required
The honest trade
- No enforced schema means nothing stops a record missing a field it needs
- No joins means duplication, and duplication means update anomalies return
- Weaker transactions — many non-relational stores offer only eventual consistency
- Fewer guarantees overall: the database no longer enforces what you assumed
- And SQL skills do not transfer — every system has its own query language
"NoSQL is more modern" is not a justification: These are trades, not upgrades. Relational databases remain the right answer for most business data precisely because they enforce structure and transactions.
An exam answer choosing a document store must say what about this data does not fit tables.
How this is tested — you must match a storage model to what the data and the queries actually look like. It comes up two ways:
Paper 1 Section A
- Outline the different types of database, 3-4 marks
- Identify a suitable type for a scenario
- State one feature of a graph or document store
Paper 1 Section B — case study
- Justify a choice against the relational default
- Explain what the choice gives up
The classic trap: Choosing a non-relational store because it sounds modern. These are trades: an answer must say what about this data does not fit tables, and what guarantee is being surrendered in exchange.
IB-style questionSuggest[5 marks]
A social network must answer "which of my friends' friends live in my city?" for millions of users. Suggest a suitable database type, justify it, and state one drawback.
Model answer plan
See the mark-by-mark plan — for / against / judgement, with marking guidance — in study mode.