Today’s world is a confusing place. There are literally 1000 of choices available to us, in almost every domain. To take a mundane example there must be about 40 or 50 places to get lunch within easy walking distance of where I work, one could waste a lot of mental energy weighing up the merits or each restaurant and sandwich bar or you could do as I do and eat at the same place most days. It’s a mental shortcut, rather that weighing up the merits or each place and choosing the best I simple take one that I know to be good enough.

Now that first world lives are so full of choice mental shortcuts are an important tool for saving mental energy us and keeping us sane. If every minor choice had to be weight and measured and mulled over then we would be on a quick route to mental burn out. So a lot of the time mental shortcuts are a good thing. Over reliance on mental short cuts can be a bad thing. This is because they can lull us into a false sense of security and lead us take important decisions without thinking it though properly. It’s fine, and even necessary, to use a mental shortcut for the little things in life, like where to eat lunch but using a mental shortcut for bigger decisions is probably the wrong thing to do. Choosing to take a mortgage from your current bank without looking at other options, simple because you feel you can trust your current bank is probably the wrong thing to do, likewise buying a car simply because saw one and thought it looked nice is probably a bad thing to do if haven’t taken the time to look at fuel consumption and maintenance costs. The key is to know when you are using a mental short and to occasionally question whether it might be worth digging a little deeper.

The world of software development is littered with mental shortcuts because there are so many choices open to developers these days. Consider the world of data access, and limiting ourselves to the world of .NET, here we have the choice of two fully blown ORMs and several light weight Micro-ORMs, weighing the merits of each one is not easier.

However the world of data access is still relatively open, and people do take the time to consider what ORM or other type strategy to use. In the world of data storage it is the relational database that is king; many people would not consider using anything else for their data-storage. Perhaps once it was the case that relational databases were the only viable choice for data-storage but I now believe this is no longer the case. The so called NoSql movement has bought with it a lot of new data-storage options which aim to tackle different kinds of data-storage problems, each with its own set of merits and inconveniences. This newly available choice means that simply using a relational database for a project is now a mental shortcut, and a mental shortcut that could lead you to the wrong choice.

Why would relational databases be a wrong choice? Well if you look carefully at the kinds of problem there optimized to solve they are often tackling the kinds of problems that were faced in IT when relational were first conceived in the late 70s and early 80s. Relational database look give you a very optimized storage size though normalization of your database schema, as disks, and other kinds of storage hardware, have become cheaper and this is less and less of a problem. Relational databases also aim to give you several views on the same data. This was useful in the old days when relational databases and the hardware needed run them were very expensive, as it meant several applications could share the same relational database reducing hardware and software costs and giving a rudimentary kind of application integration. However this kinds of application integration gives also sorts of headaches and has since been labeled an anti-pattern. It cans still be useful to have several views on the same set of data, the most common use case is to allow power uses to explore the data, but even this use case tends to be relatively rare. So although the idea of having several views on the same data can be a good thing it is also the thing that causes much of the ORM pain, there is no one clear way to map your objects to a relational database scheme so it is necessary to spends sometime choosing how the will be mapped to the schema and vice versa. So if your application just wants to save some state and get it back at some point and want to side step the whole problematic “ORM” choice then good option might be to look at other kinds of data-store.

It’s true that many of the NoSql databases aim to tackle specialized data-storage problems so if your application it’s fairly standards then these may not be for you. However, for me, the “document databases”, such as MongoDb, CoucheDb and RavenDb, stand out as data-stores that address a fairly standard data access needs so are a good choice for a replacement for a relational database. The documents that a “document database” works with map much more easily to object graphs of a programming language such as Java, C#, and even F#, so there’s no need for a heavy weight ORM style mapping, a nice lightweight JSON serializer is all you really need. It’s true that document style database generally aim to make sharding easier, and therefore create “internet scale” data-store, but in my opinion you don’t necessarily need to be facebook or twitter to justify there use. They aim to make sharding easier moving to a denormalized view of the world where each document contains its own dependencies, so data can be more easily spread across servers. However, this does just make sharding easier it also means it’s much easier to map an object graph to a document and this removes much of the pain that can be experienced when working with a relational database.

I’ve briefly tested the three document databases I mentioned before, MongoDb, CouchDb and RavenDb, and of theses RavenDb is my favorite. It’s true that part of that was the RavenDb client API supports F#’s record types out of the box (and the client API is also very extensible), whereas the other two don’t. However, there are quite a few other things I like about RavenDb. The best of all is RavenDb’s ease of use, this seems to have been foremost in the designers mind in everything from the client APIs thought to installation and the management tools. I think this is something to do with Ayende’s philosophy of trying to “drop you into the pit of success”. I also think it’s neat how RavenDb optimized for reads, which tend to be a much more common operation that writes. I believe one of the ways it achieves this is by processing indexes in the background, so while results of writes may not appear immediately you’ll never kill read performance by locking an index for an update (I believe CoucheDb does something similar).

So in conclusion I’m not saying that relational databases are dead, far from it, they’re still a good fit for certain type of problem. What I am saying is they are no long the only option for data-storage, and in many cases you may find using a document style database eases your development process.