我有以下对象公司，用户和订单（包含订单行）。用户的下订单包含一个或多个订单，这些订单与公司有关。可以为该公司下达订单的时间仅为一周。
我不确定在哪里放置订单数组，如果它是自己的集合，其中包含指向用户的链接和公司的链接，或者它应该位于公司下面还是最终应该是订单坐在用户下面。
数字明智我需要在订单中计划50k +。
明智地说，我可能会主要关注公司的订单，但我需要找到一个基于特定用户的公司订单。
答案 0 :(得分：11)
1）对于来自SQL世界（例如我自己）的人们来说，最难学习MongoDB的是模式设计的新风格。在SQL世界中，一切都进入第三范式。人们开始认为有一种正确的方法来设计他们的模式，因为通常只有一种。
在MongoDB世界中，没有一种最佳的架构设计。更准确地说，在MongoDB中，模式设计取决于应用程序如何访问数据。
2）以下是为MongoDB设计好的架构时需要回答的关键问题：
你在这里谈论的是建立多对一关系：
使用SQL，您将创建一对具有主键/外键关系的主/明细表。在MongoDB中，您有许多选择：您可以嵌入数据，可以创建链接关系，可以复制和非规范化数据，也可以使用混合方法。
正确的方法取决于许多有关您的应用程序用例的详细信息，其中许多是您未提供的。
3）这是我最好的猜测 - 这只是猜测 - 对于你来说是一个好的架构。
a）为用户，公司和订单设置单独的集合
如果您正在查看50k +订单，那么嵌入单个文档的内容太多了。将它们作为单独的集合将允许您从公司和用户文档中引用它们。
b）在公司和用户文档中有一系列对订单文档的引用。这使查询“查找此公司的所有订单”成为单文档查询
c）如果您的查询模式支持它，您可能还有一个重复的链接，从订单返回到拥有公司和/或用户。
d）假设订单行对于单个订单是唯一的，您可以将订单行嵌入订单文档中的数组中。
e）如果您的订单行引用回单个产品，您可能希望拥有单独的产品系列，并在订单行子文档中包含对产品文档的引用
4）以下是关于MongoDB架构设计的一些很好的一般参考资料。
MongoDB演示文稿：
以下是一些关于MongoDB架构设计的书籍，我认为你会发现它很有用：
以下是一些示例架构设计：
请注意，“MongoDB in Action”一书中包含电子商务应用程序的示例模式，这与您尝试构建的模式非常相似 - 我建议您查看它。