I like to think about document databases as a natural candidate for Domain Driven Design applications. When using a relational database, we are instructed to think in terms of Aggregates and always go through an aggregate. The problem with that is that it tends to produce very bad performance in many instances, as we need to traverse the aggregate associations, or specialized knowledge in each context. With a document database, aggregates are quite natural, and highly performant, they are just the same document, after all. Standard modeling technique for a document database is to think in terms of aggregates, in fact. We discuss this in depth in the next chapter .
From my point of view, though. The major benefit is that you are dealing with documents. There is little or no impedance mismatch between objects and documents. That means that storing data in the document database is usually significantly easier than when using an RDBMS for most non trivial scenarios. It is usually quite painful to design a good physical data model for an RDBMS, because the way the data is laid out in the database and the way that we think about it in our application are drastically different. Moreover, RDBMS has this little thing called Schemas. And modifying a schema can be a painful thing indeed, especially if you have to do it on production an on multiple nodes.
Doing partial updates ( patching a document)
The major benefit of using a document database comes from the fact that while it has all the benefits of a key/value store, you aren’t limited to just querying by key. By storing information in a form that the database can understand, we can ask the server to do things for us, such as querying. The following HTTP request will find all documents where the name equals to ayende :
We can put this document in the database, under the key “ayende”. We can also get the document back by using the key “ayende”. A document database is schema free, you don’t have to define your schema ahead of time and adhere to that. This allows us to store arbitrarily complex data. If I want to store trees, or collections, or dictionaries, that is quite easy. In fact, it is so natural that you don’t really think about it.
With a document database, you are encouraged to include all of the information you need in a single document. Take a look at the post example in listing 2.1. In a relational database, we would have a link table for RelatedPosts, which would contain just the ids of the linked posts. If we wanted to get the titles of the related posts, we would need to join to the Posts table again. You can do that in a document database, but that isn’t the recommended approach. Instead, as shown in the example above, you should include all of the details that you need inside the document 1 . Using this approach, you can display the page with just a single request, leading to much better overall performance.
Document databases sharding are very simple, since each document is isolated and independent, it is very easy to simply split the data across the various sharded nodes. Doing so is very since, since there is no need to store a group of related documents together. Each document is independent and can be stored on any shard in the system. Another aspect of the non-relational nature of document databases is that documents are expected to be meaningful on their own. You can certainly store references to other documents, but if you need to refer to another document to understand what the current document means, you are probably using document databases incorrectly.