We have all probably used relational databases such as SQL server or Oracle, and know how they work. Well some of you may also be lucky enough to work with nice Object Orientated languages, such as C#/Java/ etc etc.
From time to time you may have been working with SQL and your object model and just thinking this doesn’t seem a great fit actually, I am constantly having to unwind my nice object model to persist it using ADO commands to translate it back to SQL and vice versa. Ok some may use a ORM which may make it easier, but the mapping is still largely 1 business object to 1 table.
Sometimes this relational approach just doesn’t seem a great fit, so what can we do about it. Well we could make use something like LINQ to Entities which is supposed to support a abstract conceptual model over your reational data, but in practice how well does this work. I get it right sometimes, but other times my SQL relationships cause me grief.
So what else can we do, well help is at hand in the way of Document databases, which typically allow the following features:
- Persists entire objects
- Support HTTP access with a nice REST api
- Allow sharding (which is a lot easier to do if you don’t have to support all those relational reference integrity things)
- Scalabilty (which is hard in relational databases, ok this comes at at price in the fact that document databases sometimes have stale data)
Anyway I have been playing with a few of these document databases of late and written about them over at codeproject, so if you want to know a bit more and how to use a few of them, have a look here:
http://www.codeproject.com/Articles/388982/Document-Databases-A-look-at-them
Enjoy
Sacha's Blog 