MongoDB 模式建模的 5 条快速规​​则

NoSQL 数据库是一种相对较新的技术，因此关于何时以及如何使用它们存在很多疑问。

我读过很多文章，都说“如果你的数据有关系，就不要用NoSQL”。这可不是真的！这就像一句我反复念叨的假咒。在大多数情况下，我们都需要对包含各种关系的数据进行建模，而NoSQL数据库已经准备好处理这些关系。关键在于我们如何对数据进行建模。

我并不是说，如果您拥有高度相关的数据，NoSQL 数据库就是最佳选择，但是，数据中存在关系并不足以成为丢弃它们的理由。

我们将重点介绍 MongoDB。它是最流行的 NoSQL 数据库（面向文档）。在我看来，它的成功部分归功于它与流行的 JavaScript 后端框架的轻松集成。此外，MongoDB 是流行的 MEAN 和 MERN 技术栈中的M。

下面，我将为您提供 5 条快速但强大的规则，供您在设计 MongoDB 模式时考虑（您也可以将它们用于类似的数据库）：

1. 一般来说，请尝试嵌入，除非您有理由不这样做。

2. 如果您要嵌入的对象可以以孤立的方式访问（在文档上下文之外访问它是有意义的），那么您就有理由不嵌入。

3. 如果嵌入对象的数组可能无限增长，那么还有另一个不嵌入的理由。一般来说，我们嵌入的文档/对象数量不应超过几百个，ObjectID 数量也不应超过几千个。

4. 将文档中一个或多个字段从多方非规范化到一方的数组中（一对多关系）可以节省一些额外的查询（应用程序级连接）。在我看来，非规范化是充分利用此类数据库的关键之一。但是，只有当非规范化的字段很少更新时，非规范化才有意义。否则，查找和更新所有实例可能会抵消我们通过非规范化节省的性能。因此，在进行非规范化之前，请考虑字段的读写比。

5. 不要害怕应用程序级连接。有了正确的索引，它们的开销几乎不会比服务器级连接高。
   （更新：MongoDB 的最新版本包含了$lookup运算符，允许我们执行服务器级连接，具体来说是 LEFT OUTER JOINS）。

请记住：设计模式时，要尽可能地适应应用程序的数据访问模式。我们希望构建数据结构，使其与应用程序查询和更新数据的方式相匹配。

如果您想了解如何在 MongoDB 中建模一对多和多对多关系的详细信息，请查看我的帖子：MongoDB 模式设计模式（I）

参考