Look alive. Here comes a buzzard.

I’ve been having a lot of fun recently learning about and playing with RavenDb.  It’s a great document database solution for .NET.  The thing that immediately blew me away is how little friction there is getting up and going.  I am writing simple POCO objects and persisting them without having to deal with ORM mapping and other headaches.

However, there are a lot of naysayers out there spreading FUD about document databases.  Why would you need to move away from a relational model that enforces relationship constraints, allows for joins, and supports advanced querying and reporting??

Now, it’s perfectly valid to point those issues out.  If you are thinking of moving to a document database you need to know what you are sacrificing.  BUT – let’s talk about the benefits for just a moment.

Document databases tend to be a closer map to your domain model than relational databases.

Consider the scenario of persisting a customer:

public class Customer {
  public string Name { get; set; }
  public Address ShippingAddress { get; set; }
  public Address BillingAddress { get; set; }
}

In a relational model you will likely have a Customers table and a CustomerAddresses table with references between the two for the addresses. In the DB you will need to make sure the foreign keys are set up correctly and you will probably want deletes from the Customers table to cascade to the CustomerAddresses table. Then you will probably want to use an ORM like NHibernate to map those tables to the customer entity itself.

Think about that for a moment – how much work did we just have to do just to persist a simple customer?? And the reason we had to do that work is because we have to transform our data from the format WE want it in – the domain model – to a format that our relational database understands – tables and columns. That transformation takes real effort and thought. And it continually bites us in the ass with select n+1 scenarios.

I think if we step back for a moment and forget all our history with relational databases and really look at the problems we are trying to solve, it will be easier to choose the best solution for our system. Just because we’ve been building applications with relational databases for the past 20+ years doesn’t mean it’s the only way – or even the best way to go.

Sure with a document database we lose some of the relational power that something like SQL provides. But I believe the gains in many systems could overshadow those losses. And if we are designing our documents well then we won’t need as many relationships as we might have needed in a relational model.