MongoDB嵌入vs SQL外键？

Question

与SQL对相同逻辑使用外键相比，MongoDB在文档中嵌入对象的能力是否有任何特殊优势？

在我看来，唯一的优点是易用性（也许是性能？），甚至看起来它很容易被抽象掉（例如Django似乎非常直观地处理SQL的外键）。

Answer 1

这归结为是否嵌入的经典问题。

在我解释更多之前，以下是一些入门链接：

• Where should I put activities timeline in mongodb, embedded in user or separately?
• MongoDB schema design -- Choose two collection approach or embedded document
• MongoDB schema for storing user location history

现在更具体地回答。

您必须记住SQL中的外键的服务器端使用情况：JOIN。嵌入是一次往返，可以在单个文档中获取所需的所有数据，但是连接不是，它们实际上是基于范围的两种选择，然后合并以省略重复（在某些数据集上有很大的开销）。

因此，外键的使用并非完全依赖于应用程序，它还依赖于服务器和数据库。

据说有些人误解了嵌入MongoDB并尝试将所有数据整合到一个文档中。不幸的是，你应该总是尝试嵌入所有内容，以此来重新强化这一点。链接和更多内容将提供一些有用的指南。

现在我们清除了一些东西，嵌入JOIN的主要优点是：

• 单程往返
• 在很多情况下很容易更新文档，除非你嵌入了很多层次
• 可以保留与其相关的实体的实体数据

然而嵌入有一些缺陷：

• 必须将文档分页以获取其值，这在较大的文档中可能会出现问题
• 子文档被设计为对于不需要高级查询的实体而言是唯一的，因此您通常不会获得两个相互关联的独立实体，即post可以嵌入comments而不是user由于查询需要，可能不会嵌入posts。
• 深度嵌套3级以上会影响您使用原子锁等功能。

因此，当使用正确的MongoDB时，嵌入可以成为SQL连接的强大功能，但您必须了解何时正确使用它。

Answer 2

Mongo的核心优势在于其数据的文档视图，当然这可以扩展到数据的“POCO”视图。像.NET中的NoRM项目这样的Mongo客户似乎与经验丰富的Fluent NHibernate用户非常相似，这并非偶然 - 您的POCO数据模型只是序列化为BSON并保存在Mongo 1：1中。不需要映射。

总的来说，这两种技术之间的最大区别在于模型以及开发人员如何考虑他们的数据。 Mongo更适合快速应用程序开发。