A good general answer is: everything. In real-world applications, using a mix of all types of database models is often the most efficient approach.
So the better question isn’t “Which database should we use?” but rather: “Where should we use each type of database model?”
Even if using all data models isn’t feasible for a business, this article will give you a deeper understanding of how different database models work — and how we can even simulate multiple models within a single database type. This might seem hacky, but modern applications’ need for polyglot persistence has pushed databases to provide functionalities beyond their original model.
Understanding Basic Terminology
Before diving deeper, let’s clarify some key concepts.
Data Model
A data model is a way of storing data. It can exist at different levels: hardware, software, or application layer. Each is complex in its own right, so abstraction is crucial.
For example, if you want to store user resume details, you don’t need to worry about how it’s stored at the electrical current level. Instead, we focus on application layer data models, which describe how data is structured and accessed, not how it’s physically retrieved.
Types of Relationships
Entities in real-world applications are often related in different ways. Understanding the type of relationship is essential for choosing the right database model.
Many-to-Many: One entity can relate to many others, and vice versa.
Example: A case can have many tests, and a test can belong to many cases.One-to-Many: One entity can have many of another entity.
Example: A person can have multiple education entries. Note that the reverse may not hold true.Many-to-One: Many entities relate to a single entity.
Example: Many users can work in the same industry, but one industry doesn’t have the same user multiple times.
With these concepts clear, understanding the role of each database model becomes simpler.
Why Different Data Models Exist
Data Locality
Data that is related and often read together should be stored together. This is called data locality.
Relational Database
Relational databases (RDBMS) are the classic approach. Many of us first encounter databases through relational tables — whether in IT or simple real-world analogies like notebook tables.
Though RDBMS feels old-fashioned, they became powerful with query languages like SQL, which allow efficient data manipulation, retrieval, and JOIN operations. Relational databases were specifically designed to optimize referenced data retrieval — technically, this is what a JOIN does.
Document Model
Document databases feel very natural to developers because they store data in objects or JSON-like structures, which reduces impedance with applications.
The main advantage of document databases is data locality — related information is stored together, making reads more efficient.
Example: Netflix can store all movies a user likes in a single document for easy retrieval.
Flexible schema design also makes document databases ideal when the data structure isn’t fixed.
Graph Model
Graph databases store data as vertices (entities) and edges (relationships). The vertices can be heterogeneous, such as users, posts, comments, or likes.
Graph databases shine in handling complex many-to-many relationships, such as social networks (Facebook, LinkedIn), where the relationships themselves are critical.
Choosing the Right Data Model
One-to-Many Relationships: Document databases work well because related data can be stored together. However, if the “many” side is independent or highly nested, a relational table with references may be better.
Many-to-One Relationships: Storing the “one” side as a reference prevents data duplication, making relational databases suitable.
Many-to-Many Relationships: These often require join tables in relational databases. For more complex relationships, graph databases are optimal.
Polyglot Persistence: Simulating Other Models
In real-world applications, relationships are usually a mix of all types. Modern databases help handle this complexity:
- MongoDB supports lookups, a form of joins.
- Relational databases now support JSON storage and manipulation.
Even as applications scale, some data remains unstructured, rapid, or requires locality (IoT, logs), so document models remain relevant.
Conclusion
The key takeaway isn’t just which database to use, but when to use each data model. A successful design balances relational, document, and graph models to best fit the application’s needs.
References
- Kleppmann, M. (2017). Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems. O’Reilly Media.
Top comments (0)