将来可以在整个应用程序中使用基于文档的数据库而不是RDBMS吗？

Question

我阅读/使用非sql数据库越多，我就越喜欢它。

OOP世界也是这样，它很容易使用，比如Rails for Frameworks。

我知道缺点。主要关注点似乎是无交易和非并发部分。我是对的吗？

这些是否是开发人员难以选择完全使用非SQL数据库的唯一功能，即使对于交易也是如此？

如果修复了这些功能，那么仅为应用程序使用基于文档的数据库会更好吗？

因为现在看来您仍然需要使用RDBMS来获取客户账单数据，而您的内容可能位于基于文档的数据库中，例如MongoDB / CouchDB / Cassandra。

有人可以对此有所了解。

Answer 1

是的，当然你可以在非关系数据模型上构建整个应用程序。作为一般规则，虽然大多数人不想这样做。问题在于基于分层/图形的数据模型（即，依赖于导航数据结构的任何模型）显着增加了复杂性并降低了数据库中查询和数据完整性的有效性。关系模型是40年前发明的，正是为了克服导航数据库中固有的缺点。

Answer 2

没有

它们似乎不适合固定架构，高容量，主要是数值数据。想想数据仓库。考虑临时分析查询。他们可以接管RDBMS首先不适合的所有（或部分）领域（人们想出XML数据库，面向对象的数据库和图形数据库等等）。 / p>

这就像Excel无法替换Word一样（不可否认，我现在看到的大多数Excel文件都比电子表格更具呈现性）。用于不同任务的不同工具。

Answer 3

简而言之，许多NoSql解决方案没有级联更新，因此如果您的应用程序的数据模式需要这样，您将以编程方式更新多个文档（即任何列），或者坚持使用基于sql的解决方案来处理此问题。

对于不同的解决方案，并发处理方式不同。

我认为这篇博客在解释使用NoSQL解决方案的一些权衡方面做得很好 http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1

Answer 4

这还取决于新的，更快的硬件的开发。

如果您使用Cassandra和MongoDB，则可以通过多台廉价计算机（向外扩展）分发数据库。对于一台计算机而言，数据集总是太大，因为人们可以收集并保留更多数据，以便收集和保存更多数据。

但是，大多数数据集都适合一台计算机，并且可以存储在SQL数据库中。也可以扩展SQL数据库，但在多台计算机上分发数据时，外键和复杂事务会变慢。

当您通过多台计算机分发数据时，您必须做出一些艰难的选择：http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html，如果您的所有数据都在一台计算机上，则无需担心CAP定理。