这不是NoSQL vs.SQL类型的问题。我对可以使用RDBMS和NoSQL数据库的组合，而的组合非常适合的方案类型感兴趣。通常，我理解“取决于情况”和手头的任务，但是我的想法是，在某些一般/常见情况下，这种组合非常有用。
上述每种类型的解决方案都有其优点和缺点-我追求的是可以充分利用和利用两者优点的情况/场景。
在我看来，电子商务就是其中之一。 RDBMS上的付款，交易等(例如ACID2)以及NoSQL数据库中的产品信息和目录。但是，合适吗？
横切关注的应用程序，例如作为另一个示例，日志记录可能非常适合于NoSQL类型的解决方案。
或者，为什么不将两种类型的技术结合使用？
编辑:重申一下，我理解SQL和NoSQL都有其固有的优点和缺点，并且某些类型的情况仅适用于上述数据存储之一。
1我知道Facebook，Google等巨人可能结合使用了这些方法，但是在几乎所有情况下，我都不认为大多数SO成员都会使用如此庞大的解决方案。更典型的日常类型的东西。
2 RavenDB是支持ACID事务的NoSQL解决方案
最佳答案
一个很好的例子可能是在多个节点上同时更新任何分布式数据存储，并且它们需要支持潜在的复杂临时查询。节点最终将是“一致的”，这意味着任何特定节点在任何时间点的数据图片中都可能存在间隙。
这非常适合RDBMS，因为可以通过关系之间的“外部”联接非常简单地处理间隙。关系模型应该比基于图形的模型更适合于此，因为图形模型依赖于不同数据元素之间的导航路径。如果缺少一个元素，则该图将分为两个图，因此任何基于路径的查询都可能无效。关系模型中不存在此问题，因为关系数据库是非导航性的-数据元素之间没有结构上的“链接”，因此针对数据的查询的“形状”不必仅因为丢失了数据就可以更改。
关于sql - 哪些类型的情况适契约(Contract)时使用关系数据库和NoSQL数据库？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/4162125/