我有以下对象公司，用户和订单（包含订单）。用户的订单有一个或多个订单，并且这些订单与公司有关。这家公司可以下订单的时间只有一周。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