Could document-based databases be used instead of RDBMS throughout the application in the future?

Question

The more I read/use non-sql databases, the more I love it.

It's so for the OOP world and it's easy to use, like Rails for Frameworks.

I know the disadvantages. The major concern seems to be the no-transaction and no-concurrency part. Am I correct?

Are these the only features making it hard for developers to choose to use non-sql databases entirely, even for transactions?

If these features were fixed, would it be more OK to only use document-based databases for an application?

Cause now it seems like you still have to use a RDBMS for customer billing data while your content could be in document-based databases like MongoDB/CouchDB/Cassandra.

Could someone shed a light on this.

Answer 1

No.

They do not seem to be appropriate for fixed-schema, high-volume, mostly numerical data. Think data warehousing. Think ad-hoc analytical queries. They could take over all (or some of the) areas where RDBMS have not been a good fit in the first place (areas where people came up with XML databases, and object-oriented databases, and graph databases, and so on).

This is just like Excel not being able to replace Word (also admittedly, most Excel files I see these days are more presentation than spreadsheet). Different tools for different tasks.

Answer 2

Yes of course you can build entire applications on non-relational data models. As a general rule though most people don't want to do that. The problem is that hierarchical/graph based data models (ie. any model that depends on navigational data structures) significantly increase the complexity and reduce the effectiveness of queries and data integrity in the database. The relational model was invented 40 years ago precisely to overcome those disadvantages inherent in navigation-based databases.

Answer 3

In short, many NoSql solutions don't have cascading updates so if your application's data schema requires this, you will either update multiple documents (ie columns whatever) programatically, or stick with a sql based solution to handle this.

Concurrency is handled differently for different solutions.

I think this blog does a good job at explaining some of the trade-offs using a NoSQL solution http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

Answer 4

It depends also on the development of new, faster hardware.

You can distribute your database over multiple cheap computers (scaling out) if you use Cassandra and MongoDB. There will always be data sets that are too large for one computer because people collect and keep more data when it is possible to collect and keep more data.

However most data sets fit on one computer and can be stored in a SQL database. It is also possible to scale out a SQL database but foreign keys and complex transactions become slow when you distribute your data over multiple machines.

You have to make some tough choices when you distribute your data over multiple machines: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html, you don't have to worry about the CAP theorem if all your data is on one machine.