· · Matthew Ford  · 2 min read

Document Stores vs Relational Databases for Domain Modelling

Document Stores vs Relational Databases for Domain Modelling

I am quite excited about the rising popularity of document stores. We have been using MongoDB and CouchDB for some time now, both for internal and client projects. Both databases are similar (although built on different technologies) as they are schema-free, scalable, and document-oriented.

The concept of a document database isn’t new. It was pioneered by MUMPS in the 1970s for health-care and financial applications, and by IBM in 1989 with the Lotus Notes Database. It’s interesting to see the main concepts behind these legacy databases evolve and reemerge in new open-source projects.

Benefits of document stores

The NoSQL argument is that data should not be stored only in SQL databases, but should utilize other forms of data-store when they are better suited for the domain model. Speed and scalability are just some benefits, but I believe that the ability to quickly and concisely model complex domains is main advantage.

Modeling a CRM

Let’s take the example of a simple Customer Relationship Management system (CRM), to model a business card in a relational database you would have a number of tables, for example:

  • Contacts
  • Phone Numbers
  • Email Addresses

The data in each table would have to be joined together to display all the contact details. Even in this contrived example, the data model can quickly grow in complexity as you include more types of data.

This is where the power of a document store shines through, all the contact’s information can be stored in a single document. Document stores are schema-free so you do not have to define all the possible data types, you can just add new data to the document if needed.

Possible drawbacks

As with all things there is a trade off, these databases typically lack row-level database transaction and ‘table joins’ in order to achieve higher performance. The lack of joins is not a major issue as all the related information should be in one document. However, If you currently make heavy use of database transactions, migrating to a document store isn’t a good idea.

With these drawbacks in mind, you probably don’t want to build a banking platform on-top of these databases, however for the vast majority of applications these constraints are not a problem.

Further Reading

My personal preference is currently MongoDB as it has better support for dynamic queries, but there isn’t much between the two. Following on from my previous post on MongoDB with MongoMapper and Ruby on Rails  I’ll ether do a series of blog posts or a screen-cast on building a simple application with MongoDB and Rails 3.

Do you need help with your application?

At Bit Zesty, we specialise in building and maintinaing bespoke software and intergrating AI into existing applications.

Looking to build an application, but unsure of the price? Keen to discuss our experience, processes and availability?

Back to Blog

Related Posts

View all
Brighton Ruby 2024

Brighton Ruby 2024

Brighton Ruby 2024 was nothing short of amazing. It brought together passionate Ruby developers from around the world to share knowledge, network, and have fun.

Ruby on Rails: Top 5 Gems to Enhance your Application

Ruby on Rails: Top 5 Gems to Enhance your Application

Creating a Ruby on Rails app can be a challenging task, but it can be made easier by utilizing different gems. These gems consist of third-party code libraries that can significantly speed up the development process. While some of these gems are necessary for Rails,…