Relationships Of Complex Documents In Document Databases

Question

I have been looking at a number of document databases (RavenDB, CouchDB, MongoDB) and there are two things about them that I really like and makes me what to incorporate them as much as possible and that is the schema-less natural (not that they are schema-less per-say but that it is a very flexible schema that is much easier to change than ones with RDBMS) and the fact there is a lot less impedance mismatch when mapping the database data to code.

There have a been a number of things that I have found that have prevented me from using a document database because I find I need these things all the time. Some of them I have found solutions for like unique fields. While document databases don't directly support this feature, a work around that is acceptable is creating another document with the email is the document id and then inserting the user if the insert on the email document was successful however there are there is one big thing that I don't think document database can provide me from my searching.

That feature is relationships with complex documents. One of my projects I wanted to use a document database for is a project management system. The issue with this is that there are a lot of places where I need relationships with large objects (and multiple relationships within one document). When it come to something like a task or a user, those are complex documents and having the document embedded would not be a good thing as data mismatch with these items can't happen. Now if I just reference the document then am I really getting any benefit from using a document database because now I am probably going to have a lot more queries that I need to run compared to a relational database.

While I was hopping to have most of my data be stored into a document database, the more I look at it, it seems like most of the data needs to be in a RDBMS. Am I correct in assuming this type of relationship needs a RDBMS or am I un-aware of how this can be accomplished in a document database.

Answer 1

Document-oriented databases are not designed to represent complex relationships between data because relational databases already do this nicely. ;)

It is possible to represent complex relationships in doc-dbs but doing so adversely affects performance--due to the need for complex multi-pass, multi-index queries--unless you "denormalize" your data which significantly increases resource requirements.

A simple example of this might be reorganizing data layout from:

{ 
   '_id':'abcd',
   'type':'user',
   'name':'rob'
}

{
   '_id':'zyxw',
   'type':'page',
   'user_id':'abcd'
}

which requires two lookups to find all documents belonging to 'rob', to

{ 
   '_id':'abcd',
   'type':'user',
   'name':'rob'
}

{
   '_id':'zyxw',
   'type':'page',
   'owner': {
     'name':'rob'
   }
}

requiring only one.

Yes, this flies in the face of everything we've ever been told about data design but while SQL engines are optimized to fulfill complex queries by representing data in third-normal form, doc-dbs are similarly optimized for schema-less data at the expense of expressive query power (and memory.)