這篇文章是系列的最後一篇。在第一篇文章裡，我介紹了三種針對「一對多 」關係建模的基礎方案。在第二篇文章中，我介紹了對基礎方案的擴充套件：雙向關聯和反正規化化。
反正規化可以讓你避免一些應用層級別的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條重要的經驗法則2
一對多中的多是否需要乙個單獨的實體。這個關係中集合的規模是一對很少，很多，還是非常多。在掌握了以上基礎技術後，我將會介紹更為高階的主題 雙向關聯和反正規化化。雙向關聯 如果你想讓你的設計更酷，你可以讓引用的 one 端和 many 端同時儲存對方的引用。在某些場景中這個應用需要顯示任務的列表 例如顯...
資料庫設計20條
使用明確 統一的標明和列名，例如 school,schoolcourse,courceid。資料表名使用單數而不是複數，例如 studentcourse，而不是studentcourses。資料表名不要使用空格。資料表名不要使用不必要的字首或者字尾，例如使用school，而不是tblschool，或...
資料庫設計30條軍規
1 必須使用innodb儲存引擎 1.解讀 支援事務 行級鎖 併發效能更好 cpu及記憶體快取頁優化使得資源利用率更高 2 必須使用utf8字符集 1.解讀 萬國碼，無需轉碼，無亂碼風險，節省空間 3 資料表 資料字段必須加入中文注釋 1.解讀 n年後誰tm知道這個r1,r2,r3欄位是幹嘛的 4 ...