Choosing Your Database Adventure: Relational vs. Document Models Unveiled!

Dhruba Dahal | Software Engineer
3 min readJan 19, 2024

--

Photo by benjamin lehman on Unsplash

Embarking on the intricate journey of choosing the right database model is a crucial attempt in the realm of data management. As the cornerstone of any database lies in its ability to record and retrieve information effectively, the landscape is delineated into three primary categories: relational, document/NoSQL, and graph databases. In this exploration, we delve into the relational and document models from the perspective of three pivotal aspects: application code simplicity, schema flexibility, and data locality.

Application Code Simplicity

If the application deals with a simple tree-like data structure (one-to-many relationships where the entire tree is loaded at once), then the document model could be the best option. Shredding (splitting a document-like structure into multiple tables) can lead to complex schemas and, consequently, complicated application code.

On the other hand, if the application involves many-to-many relationships, the document model is less appropriate due to poor support for joins in document databases. Although the application code can perform the same task, it comes at the cost of significant complexities.

Hence, to achieve simpler application code, it is essential to consider the relationships between data items. Choose a relational model for many-to-many relationships, opt for the document model for data in a simple one-to-many tree-like structure, and consider the graph model for highly interconnected data.

Schema Flexibility

Document databases, including those with JSON support, or relational databases with key-value pairs, store records where the value is a JSON, XML string, or a binary variant. While they do not require schema-on-write (the traditional approach of relational databases), they necessitate schema-on-read by deserializing JSON strings into a certain data model, akin to dynamic (runtime) type checking in programming languages.

If the application’s data format is likely to change frequently, the schema-on-write approach can hinder adoption due to slow migrations and downtime requirements. In contrast, document databases allow for simpler inclusion of new data formats as values.

In summary, choose a document database if: a. There are several object types, and it is not feasible to put each type of object in its own table. b. External systems determine the data structure, lacking control and subject to frequent changes.

Choose a relational database if: a. All records are expected to have the same structure. b. There is no need to change the data format frequently.

Data Locality

Data locality refers to the concept of how closely related data is. It measures the number of index lookups required, with document databases typically storing related data as a single document string, offering performance advantages over splitting data into multiple tables when accessing the entire document.

However, if the application needs only a small portion of a document, loading the entire document is wasteful. Additionally, updates to a document usually require rewriting the entire document, posing a downside. Therefore, it is recommended to keep documents fairly small and avoid writes that increase document size to mitigate these performance limitations.

Big companies like Google, in Spanner database, have adopted the practice of grouping related data together for locality within a relational data model. Oracle, Cassandra, and HBase implement various concepts to achieve similar results.

Conclusion

In conclusion, the choice between relational and NoSQL databases depends on critical considerations related to the application’s data structure, flexibility requirements, and data access patterns. Each database model — relational and document/NoSQL — offers distinct advantages based on the specific needs of the application. The perspectives of application code simplicity, schema flexibility, and data locality provide valuable insights for making an informed decision.

Reference: Kleppmann, M. (2017). “Designing Data-Intensive Applications.” O’Reilly Media.

--

--