Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question
add comment

1 Answer

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.)

share|improve this answer
1  
I think the answer here is not use a document database for all your data. Have written a product before that is exactly this, a RDMS is the perfect (sorta) fit for this. Complex relationships that exist in project plans are important and having to deal with those in a document database will likely cause you pain. Easy answer is use both, just the one that is most fitting in each case. –  Travis May 17 '11 at 21:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.