面向文档的数据库是否具有完整性？
我有 MySQL 背景，对面向文档的数据库感兴趣，特别是 CouchDB。我感兴趣的事情之一是数据完整性。面向文档的数据库如何处理这个问题？例如，在 RDBMS 中，有一些方法可以防止记录重复，或者保证如果您有一点信息，就会有另一点信息，否则就没有。
我想更广泛地说，我的问题是，与 DODB 用于解决的问题相比，RDBMS 适合解决什么类型的问题？我查看了其他一些 stackoverflow 问题以寻求解释，但没有找到任何好的问题。
此外，利用我的数据库，我做了很多报告，包括求和和平均值以及历史趋势。这适合面向文档的数据库吗？
I'm coming from a MySQL background, and I'm interested in document-oriented databases, specifically CouchDB. One of the things I'm interested in is data integrity. How do document-oriented databases handle this? For instance, in RDBMSes, there are ways to prevent duplication of records, or guaranteeing that if you have one bit of information, you will have another, or else none at all.
I guess more broadly, my question is, what types of problems are RDBMSes cut out for, compared to problems that DODBes are used for? I looked on some of the other stackoverflow questions for an explanation, but didn't find any good ones.
Also, with my databases at work, I do a lot of reporting, with summing and averaging values, and historical trending. Is this something appropriate for document-oriented databases?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
大多数文档数据库仅支持非常有限的完整性或不支持完整性检查。他们依靠应用程序来确保数据正确。我可以告诉你 CouchDB 中的情况。
到第二部分。我认为 RDBMS 在报告和分析数据方面做得非常好。事实上，您可以通过连接、聚合、函数等对数据运行复杂的查询，这使得 RDBMS 成为一个非常强大的报告工具。
文档数据库非常适合存储“实时”应用程序数据。将检索对象图存储到文档数据库中非常容易。无模式设计可以轻松扩展模型以获得新的应用程序功能。然而，只有当您可以将应用程序数据拆分为漂亮的文档时，这才有效。否则你会失去很多优雅。
如果您主要想做报告，我更喜欢 RDBMS。当存储大量平面、简单的记录时，很容易对其进行报告。工具等非常适合报告。然而，当想要对复杂的结构化数据进行报告时，您可能仍然最好使用其他数据库设计而不是 RDBMS。
然而，这并不意味着您需要将自己局限于 RDBMS。您可以将这两种技术结合起来。想象一个博客软件。您将博客文章和评论等“实时”应用程序数据存储到文档数据库中。用于报告的数据（例如点击和登录统计信息）存储在 RDBMS 中。另请参阅Rob Conerys 帖子。
Most of the document-databases have only support very limited integrity or no integrity checks. They rely on the application to ensure that the data is correct. I can tell you how it is in CouchDB.
To the second part. I think RDBMS do very well at reporting and analyzing data. The fact that you can run complex queries on the data with joins, aggregations, functions etc make RDBMS a very powerful reporting-tool.
Document-databases do really well for storing the 'live' application-data. It very easy to store an retrieve object-graph into document-databases. The schema-free design makes it easy to extends the model for new application features. However this only works if you can split your application-data into nice documents. Otherwise you loose a lot of the elegance.
If you want to do mostly reporting, I would prefer a RDBMS. When to store lots of flat, simple records it very easy to do reporting on it. The tooling etc. is perfect for reporting. However when want to do reporting on complex structured data, you probably still better of with another database desgine than a RDBMS.
However this doesn't mean you need to limit yourself to RDBMS. You could combine the two technologies. Imagine a blog-software. You store the 'live' application data like blog-posts and comments into the documentdatabase. Data for reporting like click- and login-statistics is stored in a RDBMS. See also Rob Conerys post.