考虑到数据库中的实际数据，我如何在 RDBMS 和 DocDBMS 之间进行选择？
我并不是在这里寻求一场圣战，我正在思考分布式架构，并且希望了解如何在 RDBMS 与 DocDBMS 之间进行选择？
我们不能否认使用 RDBMS（即 MySQL、PostgreSQL、MS Sql Server 等）所具有的强大功能，它们已经发展了 30 多年，许多问题已经得到思考和解决。
我们还需要考虑到 NoSQL/DocDBMS 运动（MongoDB、CouchDB 等）有其自身的优势，特别是在数据存储、关联和复制的方式方面。
仅考虑数据及其结构时，我什么时候会选择使用基于文档的数据库，什么时候会使用关系数据库？
我会不想讨论一种解决方案与另一种解决方案相对于某人最喜欢的语言或平台的优点。请让讨论指向数据类型（即金融交易、博客、CMS 页面、购物车等）及其结构（数据点之间的关系 - 即与其评论相关的博客文章）。
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 points - i.e. blog post related to its comments).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
RDBMS 简直是一个优秀的全能型产品，它已经持续了 30 年，并且没有任何衰退的迹象。
像 NoSQL 之类的东西对于某些用途来说是“特殊情况”。
当我有文档库或类似库时，我会使用文档数据库。其他一切都是 RDBMS。
抛开数据不谈，如果您想出售该系统，那么您可能必须以 SQL Server 或 Oracle 等 RDBMS 为目标，以确保它在客户的基础设施上受到支持
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
如果您的数据是结构化的，那么 RMDBS 似乎是显而易见的选择，如果它是非结构化数据（例如文档），那么 DocDBMS 听起来最好。
RMDBS 更像是一种“后端”工具，您可以使用它来提供您正在开发的系统的后端。
当您说 DocDBMS 时，我认为您更多的是指文档管理系统（？）——这更像是一个完整的解决方案，其中包括针对最终用户的（文档）数据管理功能。
对我来说，NoSQL 只是 RMDBS 的一个变体 - 但用于更具体/利基的需求。
至于如何选择：列出相关的 NFR 列表，并对选项及其关联进行一些简单分析；首先想到的是可扩展性和性能，那么数据量和事务率呢？博士？当然还有重要的功能需求。您更担心构建的执行质量还是长期的演变质量？
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?