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 中結構化你的資料，從而令其輕鬆的適應變化，最大程度支援在你應用程式的進行你需要的查詢和更新。