《MongoDB高手課》學習記錄（第十四天）

第十四天

今天要學習的是1四、1五、1六、17章節。對比傳統的模型設計方法，做者總結本身的經驗，來說解MongoDB是怎麼樣進行模型設計的，並舉了一個分桶模型的例子。

關係模型與文檔模型的對比

傳統上來說，因爲MongoDB是經過文檔來組織數據的，因此人們認爲MongoDB是沒有模型設計的，或者不須要模型設計的。其實無論是什麼數據庫，要想高效、易用的組織數據，模型設計是必不可少的，方式方法也是相通的。

JSON文檔模型設計

1. 文檔模型設計處於物理模型設計階段，邏輯結構與物理結構基本是同樣的。
2. JSON文檔模型經過內嵌數組或者引用字段來表示關係
3. 文檔模型設計不遵循關係數據庫設計的第三範式，容許冗餘。

例子

在一個文檔中實現了全部數據的組織，固然還沒考慮性能及易用性等等方面，後面展開。

做者給出的設計步驟

我的理解就是，整理出實體/屬性/關係，而後再考慮系統的環境、讀寫的性能、數據的容量等因素調整設計，最後就是看看能不能套用一些設計模型的最佳實踐。

聯繫人管理例子

何時該使用引用方式

1. 內嵌文檔太大，數 MB 或者超過 16MB
2. 內嵌文檔或數組元素會頻繁修改
3. 內嵌數組元素會持續增加而且沒有封頂

MongoDB 引用設計的限制

1. MongoDB 對使用引用的集合之間並沒有主外鍵檢查
2. MongoDB 使用聚合框架的 $lookup 來模仿關聯查詢
3. $lookup 只支持 left outer join
4. $lookup 的關聯目標（from）不能是分片表

經驗小結

1. 90:10 規則：大部分時候你會使用內嵌來表示 1-1，1-N，N-N
2. 內嵌相似於預先聚合（關聯）
3. 內嵌後對讀操做一般有優點（減小關聯）

分桶模式

說簡單點就是得用內嵌數組將一個時間段的數據集合到一個文檔中,而不是傳統的按行存.

適用範圍

最後

今天的內容就這些,舉的幾個例子比較不錯,能夠反覆琢磨一下