MongoDB資料庫設計中6條重要的經驗法則，part 3

標籤：

原文：6 Rules of Thumb for MongoDB Schema Design: Part 3

By William Zola, Lead Technical Support Engineer at MongoDB

這篇文章是系列的最後一篇。在第一篇文章裡，我介紹了三種針對“一對多 ”關係建模的基礎方案。在第二篇文章中，我介紹了對基礎方案的擴充：雙向關聯和反範式化。

反範式可以讓你避免一些應用程式層層級的join，但是這也會讓更新變的更複雜，開銷更大。不過冗餘那些讀取頻率遠遠大於更新頻率的欄位還是值得的。

如果你還沒有讀過前兩篇文章，歡迎一覽。

讓我們回顧下這些方案

你可以採取內嵌，或者建立one端或者N端的引用，也可以三者兼而有之。

你可以在one端或者N端冗餘多個欄位

下面這些是你需要謹記的：

1、優先考慮內嵌，除非有什麼迫不得已的原因。

2、需要單獨訪問一個對象，那這個對象就不適合被內嵌到其他對象中。

3、數組不應該無限制增長。如果many端有數百個文檔對象就不要去內嵌他們可以採用引用ObjectID的方案；如果有數千個文檔對象，那麼就不要內嵌ObjectID的數組。該採取哪些方案取決於數組的大小。

4、不要害怕應用程式層層級的join：如果索引建的正確並且通過投影條件（第二章提及）限制返回的結果，那麼應用程式層層級的join並不會比關聯式資料庫中join開銷大多少。

5、在進行反範式設計時請先確認讀寫比。一個幾乎不更改只是讀取的欄位才適合冗餘到其他對象中。

6、在mongodb中如何對你的資料建模，取決於你的應用程式如何去訪問它們。資料的結構要去適應你的程式的讀寫情境。

設計指南

當你在MongoDB中對“一對多”關係進行建模，你有很多的方案可供選擇，所以你必須很謹慎的去考慮資料的結構。下面這些問題是你必須認真思考的：

關係中集合的規模有多大：是一對很少，很多，還是非常多？

對於一對多中”多“的那一端，是否需要單獨的訪問它們，還是說它們只會在父物件的上下文中被訪問。

被冗餘的欄位的讀寫的比例是多少？

資料建模設計指南

在一對很少的情況下，你可以在父文檔中內嵌數組。

在一對很多或者需要單獨訪問“N”端的資料時，你可以採用數組引用ObjectID的方式。如果可以加速你的訪問也可以在“N”端使用父引用。

在一對非常多的情況下，可以在“N”端使用父引用。

如果你打算在你的設計中引入冗餘等反範式設計，那麼你必須確保那些冗餘的資料讀取的頻率遠遠大於更新的頻率。而且你也不需要很強的一致性。因為反範式化的設計會讓你在更新冗餘欄位時付出一定的代價（更慢，非原子化）

MongoDB資料庫設計中6條重要的經驗法則,part 1

MongoDB資料庫設計中6條重要的經驗法則，part 2

MongoDB資料庫設計中6條重要的經驗法則，part 3