I strongly disagree with this view of document stores as 'easier' to work with.
For some tasks, this is undeniably true, but for most business problems I think this is just not the case. The profound irony behind this is that schema-less document stores wind-up being so much less flexible due to them being inherently very denormalized.
The good case for document stores is:
1. You have data that really is a blob independent of having relations
2. You need high-performance or map-reduce (Riak, Dynamo, etc.)
Those two use cases are really rare in the real world. For most people there's a huge amount of code that leans on RDBMS strengths such as:
1. Integrity constraints
2. Very flexible ad-hoc queries.
3. Decades worth of work on tooling to mitigate rough edges, and solve tough problems that have come up before.
To clarify, I agree that RDBMS's are fantastic, and you pointed out many of the benefits. We are not religious about SQL vs NoSQL.
For our particular use cases, we think that document stores are a better fit, but I am not arguing that document stores are universally easier or better.
For some tasks, this is undeniably true, but for most business problems I think this is just not the case. The profound irony behind this is that schema-less document stores wind-up being so much less flexible due to them being inherently very denormalized.
The good case for document stores is:
1. You have data that really is a blob independent of having relations 2. You need high-performance or map-reduce (Riak, Dynamo, etc.)
Those two use cases are really rare in the real world. For most people there's a huge amount of code that leans on RDBMS strengths such as:
1. Integrity constraints 2. Very flexible ad-hoc queries. 3. Decades worth of work on tooling to mitigate rough edges, and solve tough problems that have come up before.