Comparing Data Models and Choosing One

Concept

This note closes Phase 3 by putting every model in one table and giving a repeatable way to choose between them. Phase 16 returns to the NoSQL families in detail; here they appear only as the sixth column.

The full comparison

A method for choosing

Choose from the questions the data must answer, not from what is fashionable. Work down this list and stop at the first clear answer.

1. Is the data naturally tabular, with relationships that matter and rules that must always hold? Relational. This covers the large majority of business systems and should be the default.
2. Do transactions span several records and must they be all or nothing? Relational or object relational. Do not relax this requirement casually — money, stock and bookings all depend on it.
3. Is the dominant access pattern fetching one whole nested document by its key? A document store is a reasonable fit.
4. Is it a simple lookup by key at very high rate? A key value store.
5. Are relationships themselves the main subject, traversed many levels deep? A graph model.
6. Is the data enormous, append heavy and queried by a known key range? A wide column store.
7. Is the data deeply nested objects with behaviour, in engineering or scientific work? Object oriented or object relational.

The honest default is relational. Most systems that abandoned it did so for a scale they never reached, and paid for it with integrity problems that the database would have prevented for free.

Example

Four systems, four answers

 College results
   tabular, relationships matter, marks must obey rules,
   modest scale                                 -> RELATIONAL

 Product catalogue where every category has
 different attributes, read whole by id
                                                -> DOCUMENT

 Session store, millions of reads per minute,
 one value per key, disposable
                                                -> KEY VALUE

 "Which colleagues are within three degrees of
 this person", asked constantly
                                                -> GRAPH

Note that the FIRST one is the shape of most real systems.

Mixing models

Real systems commonly use more than one, deliberately. A relational database holds the orders because they must be correct; a key value store holds the sessions because they must be fast; a search index holds the text because that is what it is for. This is called polyglot persistence, and its cost is that consistency between the stores becomes your responsibility.

Common mistakes

• Choosing a model by popularity. Choose by access pattern, consistency requirement and scale.
• Assuming NoSQL means no schema. The schema moves into the application, where nothing enforces it.
• Adopting a distributed store for a dataset that fits on one machine. You inherit distributed problems and gain nothing.
• Treating the models as generations. They are alternatives with different strengths, not a queue in which the newest wins.

Exam and interview questions

1. Compare all major data models in a table across at least six points.
2. Give a method for choosing a data model for a new application.
3. Which model would you choose for a social network friendship query, and why?
4. What is polyglot persistence and what does it cost?
5. Why is relational still the sensible default?

Practice

1. Choose a model for each and justify in one line: hospital records, a chat application, a recommendation engine, a fee payment system, a log of sensor readings.
2. List three questions to ask a client before recommending a data model.
3. Describe a system that would reasonably use three different models at once.

Conclusion

Every model is a set of trade offs between structure, flexibility, guarantees and scale. Choose from the access patterns and the consistency the data actually requires, default to relational, and add another model only when a specific requirement makes the case.