考虑到 NoSQL 用于分布式设置的优势和大量数据/水平可扩展性以实现快速访问，对于某些实现来说，像 mongodb 这样的 nosql 数据库是一个好主意。
然而，nosql 数据库似乎有其优点和缺点。 似乎关系数据库带来了明显的优势，特别是对于当前基于关系数据库构建的应用程序。
在这种情况下，我想问一下，建立两个数据库是否有优势，一个用于 NoSQL 类型的数据，另一个用于其他由需要关系数据库类型约束的业务需求预测的用例和特点？ （跨表的联接和事务）。这是一种实用且普遍的做法吗？
举个例子，Twitter 或 facebook 有一个用于用户登录信息和用户帐户的关系模型而不是存储 NoSQL 数据库的其他动态数据是否有意义？
【问题讨论】：
首先，让我说@Bill Karwin 的回答非常周到，我同意他写的大部分内容。
现在，我有一个经过几年发展的应用程序。在使用 SQL 创建第一代数据库时，NoSql 还没有真正出现。数据库增长为包含大量表以及更多的函数和存储过程。我们两个人最终全职工作只是为了维护它。优化查询几乎花费了我所有的时间。
在第一个 DBA 离开后，我独自一人，我重新设计了概念以使用“NoSql”概念，但在关系 DB 表中（当时，Mongo 和类似的处于 alpha/beta 阶段）。在这种方法中减少到大约 10 个不同的表。它取得了一定的成功，但在速度方面并没有给我们带来太多好处。不过，它确实让我们避免雇用其他 DBA。
第三次，我实现了一个混合关系/无 sql 数据模型。关系用于分层数据，但保持相同的“开放表”概念并且没有很多表列。查询相当快，但仍然跟不上我们的负载。
最后，我决定完全放弃 Sql 数据库（大约一年前）。我放弃了动态编写查询的灵活性，但是 Mongo 和 Couchbase 现在已经有足够的查询能力了，我觉得很舒服。在我的 NoSql 应用程序中，性能优势远远超过了冗余数据的缺点。
我的观点是，我的案例确实最适合 SQL 数据库，但由于我能够重新设计我的应用程序，它实际上在 NoSql 环境中表现更好，我可以在我的自己的，兼职的，没有任何帮助。因此，SQL 关系数据库的优势虽然强大，但实现起来可能非常昂贵，您应该在决策和设计中考虑到这一点。
【讨论】：
是的，当然。许多成功的公司正是这样做的。
NoSQL 数据库旨在优化特定查询负载的访问，就像非规范化关系数据库可用于帮助特定查询一样。
而规范化的关系数据库旨在防止数据的冗余或异常存储。
这两个目标在适当的环境中都很重要。所以关系和非关系都有一席之地（非规范化的 RDBMS 适合后一类）。
任何一个 SQL 或 NoSQL 数据库可能看起来不理想的地方是，当它们不恰当地用于另一个更好的任务时。
纯粹的规范化 RDBMS 是万事通，从支持各种查询的意义上说，无所不能。但是，如果您不需要支持针对某个数据集的各种查询，那么非规范化或 NoSQL 都可以提供帮助。
当您厌倦了设计模式和不时执行 ALTER TABLE 添加列时，NoSQL 很有吸引力。但是，如果您为一个查询负载设计 NoSQL 数据库，然后发现您还需要支持针对相同数据的完全不同的查询负载，您可能会将自己逼入绝境。您要么遭受缓慢的查询，要么克隆整个数据集，但存储在不同的结构中。
【讨论】：