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.
