【译】MongoDB Shema 设计的6条经验法则 3

6 Rules of Thumb for MongoDB Schema Design: Part 3

做者 William Zola， Lead Technical Support Engineer at MongoDB

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

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

若是你忘记了，参看 第一部分和 第二部分 。

看看这些选择

回顾一下：

• 你能够 内嵌， 从 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端 对象，仍是只是须要在父对象的上下文中进行访问？

• 这个特定字段的读取与更新的比率是多少？

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

• 对与 1对少， 你可使用一组内嵌式的文档。

• 对于 1对不少 或者当 N端 必须单独使用的状况中，你应该使用 引用数组 的方式。你也能够 用在N端使用 父引用 的方法 若是这样作能够优化的你数据访问模式。

• 对于 1对很是， 你应当使用在存放 N端 的文档中 使用 父引用 。

一旦你决定了数据的总体结构，那你就能够选择在不一样文档间进行反范式化，经过 将 1端的数据 范式化到 N端 或者 从 N端 反范式化 到 1端。

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

生产力和灵活性

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