开发者

Considering the actual data in a db, how would I choose between a RDBMS and a DocDBMS?

开发者 https://www.devze.com 2022-12-20 09:59 出处:网络
I\'m not looking for a holy war here, I am thinking through a distributed architecture and would like input on How do I choose between a RDBMS vs. a DocDBMS?

I'm not looking for a holy war here, I am thinking through a distributed architecture and would like input on How do I choose between a RDBMS vs. a DocDBMS?

We cannot deny the power that can be had by using a RDBMS (i.e. MySQL, PostgreSQL, MS Sql Server, etc), they have been in development for more than 30 years and many issues have been thought through and addressed.

We also need to consider that the NoSQL/DocDBMS movement (MongoDB, CouchDB, etc) has its own strengths, especially in the manner in which data is stored, related and replicated.

When considering DATA and its STRUCTURE only, when would I choose to use a document based db and when would I used a relational db?

I do not want to discuss the merits of one solution vs another in relation to somebody's favorite language or platform. Please keep the discussion pointed to types of data (i.e. financial transactions, blogs, CMS pages, shopping carts, etc) and their structure (relationships between data开发者_JAVA技巧 points - i.e. blog post related to its comments).


An RDBMS is simply a good all rounder that has lasted for 30 years and shows no sign of flagging. Things like NoSQL etc are "special case" for certain uses.

I'd use a document database when I have a document library or similar. Everything else is an RDBMS.

Data aside, if you want to sell this system then you may have to target an RDBMS like SQL Server or Oracle to ensure it's supportable on your customer's infrastructure


If your data is structured the an RMDBS seems the obvious choice, if it's an unstructured data - such as a document, then a DocDBMS sounds best.

RMDBS's are more of a 'backend' tool, you'd use it to provide the backend of a system you were developing.

When you say DocDBMS I'm thinking you mean more of a document management system (?) - which is more of an entire solution which would include (document) data management functionality aimed at end users.

To me, NoSQL is simply a variant on an RMDBS - but for more sprecific / niche needs.

As to how to choose: draw up a list of NFR's which are relevant and do some simple analysis of the options and how they relate; scalability and performance come to mind, what about data volumes and transaction rates? DR? And of course important functional needs. Are you more worried about execution qualities of whats built or longer-term evolution qualities?

0

精彩评论

暂无评论...
验证码 换一张
取 消