Relationships decide the best data model fit
Early database systems modeled data as a hierarchy of records. It made storing and handling one-to-many relationships easy, but representing many-to-one and many-to-many relationships was difficult. Since then, data relationships have single-handedly pushed for the evolution of data models.
While the relational model was proposed as a solution and gained popularity in the 1980s, we now have multiple data models that support relationships to varying degrees. Understanding the underlying support offered by data models is crucial. Otherwise Applications have to make up for the shortcomings of data models.
Document Data Models
If you deal with data that is mostly devoid of relationships, document databases are your best bet - Document data models are "Hierarchical models on steroids". Document databases are similar to hierarchical databases with one difference: instead of storing denormalized data in the database, they can store references (document references, like foreign keys) pointing to a different document record.
Best fit if:
- Your data sets are primarily self-enclosed and do not have many relationships.
- You want to improve Data Locality for the sake of performance.
- You have or wish to have Schemaless data sets or want to specify schemas only on read.
Relational Data Models
Relational data models have dominated the database landscape since the 1980s and have proven to versatile enough to accommodate most application domains. If your domain rich relationships and you want to represent them as part of your data and applications, relational databases are a good bet.
Best fit if:
- Your data relationships are well-defined.
- Performing data joins does not hamper application performance at peak load.
- You want to enforce data schemas for all incoming data.
- You want standalone access and wish to work with data directly with independent queries.
Graph Data Models
When your application thrives on data relationships, and you want to discover new (or hidden) relationships in data, graph databases are a great choice.
Best fit if:
- You have many-to-many relationships.
- Your application performance is impacted by the number of joins performed to respond to queries.
- Your relationships are flexible and growing or unknown at the start.
- You want to discover new connections between domain entities.
It is important to remember that The right data model can change over time. As your system scales with business, you may discover new use cases that better fit in a different data model. It is often best to handle disparate data models in separate microservices. However, it is still valid to migrate the application's data model en masse to a different data model, if necessary.
Ultimately, aspects like Fault Tolerance, Data Locality, and Concurrency do play a role in the decision of choosing a database. But data models are often the driving factors.