我有以下對象公司，用戶和訂單（包含訂單）。用戶的訂單有一個或多個訂單，並且這些訂單與公司有關。這家公司可以下訂單的時間只有一週。MongoDB Schema設計訂購服務
我不確定在哪裏放置訂單數組，它應該是它自己的一個集合，它包含一個鏈接到用戶和一個鏈接到公司，或者它應該坐在公司下或最後應該訂單被置於用戶之下。
數字明智我需要計劃在訂單50k +。
查詢明智，我可能會主要看公司的訂單，但我需要找到一個公司的訂單爲特定用戶。
1）對於來自SQL世界的人（比如我自己）來說，瞭解MongoDB最難的一件事是模式設計的新風格。在SQL世界中，一切都進入第三範式。人們開始認爲有一個正確的方式來設計他們的模式，因爲通常有一個。
在MongoDB的世界裏，沒有一個最好的模式設計。更準確地說，在MongoDB模式設計中，取決於應用程序將如何訪問數據。
2）在這裏，你需要以設計MongoDB的一個很好的模式來回答的關鍵問題：
什麼你在這裏談論的造型多到一的關係：
使用SQL，您將創建一對主/明細表y /外鍵關係。在MongoDB中，您有多種選擇：可以嵌入數據，可以創建鏈接關係，可以複製和非規範化數據，也可以使用混合方法。
正確的方法將取決於您的應用程序的用例的許多細節，其中許多您沒有提供。
3）這是我最好的猜測 - 這只是一個猜測 - 對於一個好的模式適合你。
一）對用戶，企業和訂單
單獨集合如果您正在尋找在50K +訂單，有太多的單個文檔中嵌入。把它們作爲一個單獨的集合可以讓你從公司和用戶文檔中引用它們。
b）在公司和用戶文檔中都有一系列對訂單文檔的引用。這使查詢「查找此公司的所有訂單」一個單一文檔查詢
c）如果您的查詢模式支持它，您可能還有一個從訂單到擁有公司和/或用戶的重複鏈接。
d）假設訂單行對於單個訂單是唯一的，您可以將訂單行嵌入訂單文檔中的數組中。
E）如果您的訂單行指回單品，你可能希望有一個獨立的產品集合，包括訂單行子文檔
4到產品文檔的引用）這裏有一些有關MongoDB模式設計的一般參考資料。
MongoDB的介紹：
這裏有幾個關於MongoDB的架構設計的書籍，我想你會發現有用：
下面是一些示例架構設計：
注意 「的MongoDB在行動」 一書包括樣本電子商務應用程序的模式，這與您正在嘗試構建的模式非常相似 - 我建議您檢查一下。
我見過的更好的解釋之一。做得很好。 – 2013-06-13 15:20:13