最近我一直在和MongoDB一起工作，我不得不说我真的很喜欢它.然而，这是一个完全不同类型的数据库，而我是被使用的.我注意到，对于某些类型的数据，它肯定更好，但是对于高度规范化的数据库，它可能不是最佳 Select .
然而，在我看来，它完全可以取代任何关系数据库，而且在大多数情况下性能更好，这令人难以置信.这让我想问几个问题:
面向文档的数据库是否已经发展成为下一代数据库，并基本上完全取代关系数据库？
不会.面向文档的数据库(如MongoDB)非常擅长我们在现代网站中通常看到的任务类型(快速查找单个项目或小项目集).
但他们在关系系统上做了一些重大的权衡.如果没有像ACID合规性这样的东西，它们将无法取代某些RDBMS.如果你看看MongoDB这样的系统，缺乏ACID合规性是其速度如此之快的一个重要原因.
对于更适合其中之一的各种数据，同时使用面向文档的数据库和关系数据库是否有可能使项目变得更好呢？
对事实上，我正在运行一个非常大的生产网站，它同时使用这两种方法.该系统是在MySQL中启动的，但我们已经将其中的一部分迁移到了MongoDB，b/c我们需要一个键值存储，而MySQL只是不太擅长在150M记录中找到一项.
如果面向文档的数据库并不意味着要取代关系数据库，那么有没有人能举一个数据库 struct 的例子，说明它在关系数据库中绝对更好(反之亦然)？
Document-oriented databases是很好的存储数据的工具，这些数据很容易包含在"关键值"和简单的线性"父子"关系中.这里有一些简单的例子，比如博客和维基.
然而，relational databases在报告这类倾向于"以设定为基础"的事情上仍然有很强的优势.
老实说，我可以看到这样一个世界:大多数数据由面向文档的数据库"处理"，但报告是在由Map-Reduce作业(job)更新的关系数据库中完成的.