【譯】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 中結構化你的數據，從而令其輕鬆的適應變化，最大程度支持在你應用程序的進行你須要的查詢和更新。