Arguments for usage choice: RavenDB vs SQL Server - performance, reliability and simplicity [closed]

Question

What points should be taken into consideration, while choosing data layer for a web application?

Is there any preferable choice for using document database over relational ones, while developing small project over large and heavy loaded, or vice versa?

What kind of database architecture is preferred for these approaches - if I have simple database without too many relations, is it better to use one approach over another?

Answer 1

Since this question is inviting personal comment, here is my opinion:

SQL Server is not a database for storing anything except ad-hoc reporting data. It is splendid for that, ad-hoc reports, data-mining, real time relationship discovery - and its optimal for these uses because way back when Codd designed the rules, that is what it was designed for (see The Data Driven Conspiracy for more details)

Of course you can store other types of data in a relational database. For example you can serialise your domain state to a SQL Server database and retrieve that state at a later date but this is a terrible use of a relational system. So bad, in fact, that whole layers of code (so called 'data-layers', or DALs), many thousands of lines, are required to make this kind of task remotely do-able, testable, maintainable.

The great, decades long confidence trick has been for the SQL based retailers to convince us that there was no better way to store hierarchical / document data other than real-time conversion between radically different data-structures. DALs and the latest ORM have all been trumpeted but, in the end, these are nothing more than codecs to thunk your bits back and forth between different data organisations - different patterns on the disk.

Madness!

So forget all the itsy-bitsy, angels-on-a-pinhead arguments about atomicity, consistency, isolation, durability. The elephant in the room is that if you are using SQL Server and you are not a pharmaceutical company that is dynamically mining data-cubes for hidden inferences within large populations (are you?) then you are probably using the wrong technology to store your data.

If, on the other hand, you are a humble application developer - a coder who, like most of us, simply wishes to serialize domain-state in a way that does not mean learning a whole new set of ideologies and syntax then, for goodness sake, do not use a relational database. Just don't.

RavenDB? I have been using this for a while (having evolved through DB4O and CouchBase) and I can say that it does what it says on the tin. It stores my stuff and gives me it back when I ask. I did not have to write any data-layers nor use a third party ORM. I did not have to learn a structured query language and I did not have to bolt on extras to make Full Text search work (RavenDB is based on Lucene so it all 'just works'). So far so good.

But really, does it matter what you use as long as it is, for the task at hand, easy to code, fast and efficient? For normal application development RavenDB is all of these things whereas SQL Server is not. That is not to say that relational DBs are bad - let's not blame the victim - I fully acknowledge that for certain specialised developments you may indeed need something a little more ... exotic, such a relational datastore.

But just in case you are still clinging to the wreckage, you need to ask yourself this: If we had all been using simple, fast, elegant datastores that closely fitted our needs as application developers, and then I wrote an opinion piece urging you to adopt SQL Server then you would most likely laugh at me or pity me. One thing is for sure - you would not swap to SQL Server. Thus we demonstrate that inertia alone is the guiding force that keeps SQL Server tacked into the mainstream. Inertia and ignorance. Inertia, ignorance and corporate greed ....