【译】MongoDB Shema 设计的6条经验法则 3-秋月博客

作者 William Zola， Lead Technical Support Engineer at MongoDB

这是在MongoDB 中对 1对N 关系建模的最后一站。在第一篇博文中，我谈到了三个对 1对N 建模的基本方法。上一篇中，谈到了这些基本方法的一些拓展：双向引用 和 反范式化。

反范式化能能让你避免那些以高成本且复杂的更新为代价的应用级别的联接。如果那些字段的读取比更新更加频繁，那对这一两个这样的字段做反范式化是有意义的。

如果你忘记了，参看第一部分和第二部分。

看看这些选择

回顾一下：

特别是 反范式化，它给了你很多选择：如果有关系中 8个选项可以反范式化，就有 2⁸ 种不同的方式去做反范式化（包括完全不做反范式化）。在将三种不同的引用方法组合到一起，你可以有超过3000种方法来建立关系模型。

你猜会怎么样？你陷入了 “ 选择悖论 ” —— 因为你有这么多潜在的方式来建立 1对N 关系模型，现在如何建模的时候将更加困难。

这里是经验法则可以指引你通过这无数的选择。

一，使用内嵌，除非有一个明确的原因。
二，需要访问对象本身，可以是一个明确的不使用内嵌的理由。
三，数组不应该无限的增长。如果 很多 一端种有超过几百个文档，那就不要使用内嵌。如果 很多 一段中有超过几千个文档，那就不要使用 ObjectID 引用数组。高基数数组是一个明显的不使用内嵌的理由。
四，不要害怕应用程序级别的联接：如果正确索引并使用投影操作（见 [第二部分](at the expense of having more complex and expensive update)），那么应用程序级别联接并不会比关系数据库中服务器端联接的成本高。
五，考虑非范式化的读/写比率。一个经常读取且很少更新的字段是很好的反范式化的选项。如果你范
六，MongoDB 中，如何对你的数据建模大体上取决于你的特定应用程序中数据的访问模式。你可以过调整你的数据的结构，从而使之匹配你的应用程序的查询和更新数据的方式。

在 MongoDB 中建模 1对N 关系是，你有多种不同的选择，因此你必须仔细考虑你的数据的结构。

你需要考虑的主要准则有：

构建数据的的主要选择有：

对与 1对少，你可以使用一组内嵌式的文档。
对于 1对很多 或者当 N端 必须单独使用的情况中，你应该使用 引用数组 的方式。你也可以用在N端使用 父引用 的方法如果这样做可以优化的你数据访问模式。
对于 1对非常，你应当使用在存放 N端 的文档中使用 父引用 。

一旦你决定了数据的整体结构，那你就可以选择在不同文档间进行反范式化，通过将 1端的数据范式化到 N端 或者从 N端 反范式化到 1端。

这些操作只合适对经常读取，读取比更新频繁，并且对一致性没有强烈的要求的字段，因为更新被反范式化的值很慢，成本较高并且不是原子性的。

综上结果，MongoDB 能让你让你设计数据看来匹配你的应用程序的需求。你可以在 MongoDB 中结构化你的数据，从而令其轻松的适应变化，最大程度支持在你应用程序的进行你需要的查询和更新。