MongoDB的嵌套設計理念

Question

我創建其中一個公司有多個用戶的系統，客戶等，我不能決定是否進行「對象」，如用戶，一個單獨的集合或公司文件嵌入文檔。

Company (Object) -> 
    Users (Object) -> 
     Profile (Object) -> 
      ...attrs.. 
     History (Object) -> 
      ...attrs... 
    Customers -> 
     ...attrs... 

我困在關係數據庫的思維集現在，並不確定「正確」的方式與NoSQL做到這一點。你怎麼看？

當雙重嵌入式文檔（如公司>用戶 - >歷史記錄）得到可笑的大時會發生什麼？

對嵌入式文檔方法（如果有）有什麼其他缺點？再一次，我偏向於關係思維。

在此先感謝。

Answer 1

我可以在這裏給出一些一般建議，但最終將由您決定採用哪種方法。你需要詢問，以確定是否嵌入或引用的問題是：

你需要什麼數據，當您獲取大多數查詢的文檔返回？

這可能很簡單或很複雜 - 如果99％的查詢要返回相同的5個字段，答案就很明顯。如果你很少需要一段數據，那麼它是一個單獨集合的候選人。您需要進行第二次查找才能獲取這些數據，並在它們之間提供某種參考，但稀缺性使得開銷可以接受。

當然，如果你的數據集和返回值不那麼清晰，那麼它就成爲一個更復雜的問題。

如果需要頻繁使用的字段，但不是所有的需要（比如在歷史上最後5項），然後存儲它們，固定大小，在主文檔中，並在一個單獨的集合休息。這會導致一些重複並使您的更新複雜化，但在速度方面可能是一個很好的折衷。

在缺點方面 - 大量嵌入文檔不差本身，而是越來越多的一個，特別是一個無界的增長可不好。每次文檔增長時，其分配空間可能會太大，這意味着它必須移動。這不僅會在一定程度上分割您的數據，移動大量文檔，分配新空間可能是一項昂貴的操作 - 尤其是在您頻繁操作時。填充因子文檔解釋這個相當好（當移動被觸發的填充因子增加）：

http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-Overview

希望它能幫助！

Answer 2

如果您不需要查詢和自身獲得的相關數據統計等，然後使其嵌入這也加快了查詢。如果您需要爲某種目的提取此數據，請爲其創建新的集合。

Answer 3

http://www.mongodb.org/display/DOCS/Schema+Design對架構設計的一些建議，也有各種演示通過像10gen公司的成員這樣一條：http://dl.dropbox.com/u/205597/sts/sts-04-2012-mongo-and-nosql-schema.pdf

考慮到用戶的公司可能數量和歷史對象的可能數目我想你」我可能會想爲每個這些單獨收集。