collection 的單個 doc 有大小上限，現在是 16mb，這就使得你不可能把所有東西都揉到乙個 collection 裡。而且如果 collection 結構過於複雜，既會影響查詢、更新效率，也會造成維護困難和操作風險。你有嘗試過手一抖就把乙個 doc 不小心存成 null 的麼，反正我做過，要是乙個人所有資訊都在這個 collection 裡面，那感覺一定相當酸爽吧。
一般的原則是：
按照查詢方式來聚類
需要經常一起讀取的資料放一起.
在邏輯上關係緊密的資訊放在一起。
有 map-reduce/aggregation 需求的資料放在一起，這些操作都只能操作單個 collection。
按照資料量來拆分
如果發現要在 collection 裡面用陣列，陣列長度還會不斷增加，那麼應該把資料內容放到乙個專門的 collection，每條資料都引用當前這個 doc 的主鍵（就像 mysql 的 1..n 外來鍵依賴一樣）。
如果發現某個 doc 層次過深（超過 2 層），八成得考慮要拆分了，要不然效能和可維護性都會有問題。
按照有表結構的方式來設計
mongodb 是沒有表結構這個概念的，但是實際使用的時候，很少說乙個 collection 裡面存在各式各樣結構的 doc，如果發現 doc 的結構差別越來越大了，那麼應該考慮怎麼抽象成類似結構，把變化的東西扔到其他 collection 去，用外來鍵依賴的方式互相引用。
比如設計乙個使用者系統，user collection 應該放 name 等常用的資訊，也應該放 lastloginat 這些僅跟 user 相關的東西，或許應該把使用者有哪些訪問許可權的資訊也放進來，但是不要放使用者的登入日誌這種資訊會不斷增加的資訊。
至於 user 之間的關係是否存在 user collection 則需要討論。假如僅僅需要儲存使用者間的關係，記錄下好友的 uid 就行，而且好友數量也不太大，幾百個最多了，那麼我傾向於放在乙個 collection 裡。如果關係資料本身就比較複雜，或者好友數會上千，那我傾向於拆分。
另外，mongodb 官方的 資料模型設計正規化 很值得一讀，推薦去好好看看。
**：mongodb傾向於將資料都放在乙個collection下嗎？
設計原則與思想 設計原則
如何理解單一職責原則 srp solid原則並非單純的1個原則,而是由5個設計原則組成,他們分別是 單一職責原則,開閉原則,裡式替換原則,介面隔離原則和依賴反轉原則,依次對應solid中的s,o,l,i,d這五個英文本母 單一職責原則的英文是single responsibility princip...
設計原則 開閉原則
開閉原則的含義是對擴充套件開放，對修改關閉。意思就是在遇到新的需求或者變動的時候，提倡對原 擴充套件使其滿足新的需求，不提倡修改原 來達到目的。乙個專案不可能在開發完畢後就一成不變了，它總會有新的需求或者對老的需求進行更新。這樣就要盡可能的遵從設計原則中的開閉原則，這個原則告訴我們，要盡量避免對原 ...
設計原則 開閉原則
怎樣的 改動才能被定義為 擴充套件 怎樣的 改動才定義為 修改 怎樣才算滿足或者違反開閉原則？修改 意味著違反開閉原則嗎？開閉原則是最難理解，也是最難掌握，同時也是最有用的一條原則。這條原則並不是看幾篇文章，理解了其概念就能掌握和靈活應用的。要想深入理解，掌握這條原則，需要大量的實戰。開閉原則，英文...