在这里接受的答案中举一个例子：
对于博客系统，“帖子应该是一个集合。帖子作者可能是一个单独的集合，或者只是帖子中的一个字段，如果只是一个电子邮件地址。cmets 应该是帖子中的嵌入对象以提高性能。”
如果是这种情况，这是否意味着每次我的应用显示博客文章时，我都会加载对该文章发表的每条评论？如果有 3,729 cmets 怎么办？这不会破坏数据库连接、SQL 或 NoSQL 吗？还有一个明显的场景，当我加载博客文章时，我最初只想显示前 10 个 cmets。
【问题讨论】：
标签： mongodb relationship nosql
不确定这是否能回答您的问题，但无论如何您可以通过两种方式限制博客 cmets 的数量：
$slice 运算符仅加载最后 10 个或博客 cmets 范围db.blogs.find( {_id : someValue}, { comments: { $slice: -10 } } )
将返回最后 10 个 cmets
db.blogs.find( {_id : someValue}, { comments: { $slice: [-10, 10] } } )
将返回下一个 10 cmets
【讨论】：
comments.author你可以使用$elemMatch找到这样的文档
文档数据库不是关系数据库。您不能先构建数据库模型，然后再决定各种有趣的查询方式。相反，您应该首先确定要支持的访问模式，然后相应地设计文档模式。
因此，为了回答您的问题，我们真正需要知道的是您打算如何使用这些数据。显示与帖子关联的 cmets 与显示来自特定作者的所有 cmets 截然不同。这些要求中的每一个都将决定不同的设计，同时支持它们。
这本身对您来说可能是有用的信息（？），但我怀疑您想要更具体的答案 :) 所以请添加一些有关您预期用途的其他详细信息。
添加更多信息： 在决定策略时有一些“做”和“不做”：
DO：针对常见用例进行优化。通常有 20/80 的细分，其中 20% 的 UX 驱动 80% 的负载 - 主页/登陆页面是一个典型的例子。首要任务是确保这些尽可能高效。确保您的数据模型允许 A）在单个 IO 请求中加载它们或 B）缓存友好
不要：不要落入可怕的“N+1”陷阱。当您的数据模型强制您进行 N 次调用以加载 N 个实体时，就会出现这种模式，通常在此之前还有一个额外的调用以获取 N 个 ID 的列表。这是一个杀手，尤其是与#3...
DO：始终限制（通过 UX）您愿意获取的数据量。如果用户有 3729 个 cmets，您显然不会一次全部获取它们。即使从数据库的角度来看它是可行的，用户体验也会很糟糕。这就是搜索引擎使用“下一个 20 个结果”范式的原因。因此，您可以（例如）将数据库结构与 UX 对齐，并将 cmets 保存为 20 个块。然后每次页面刷新都涉及一个 DB get。
DO：平衡读取和写入要求。某些类型的系统是读取繁重的，您可以假设每次写入都会有很多读取（StackOverflow 就是一个很好的例子）。因此，为了提高读取性能，提高写入成本是有意义的。例如，数据非规范化和复制。其他系统均衡甚至写繁重，需要其他方法
做：利用时间维度来发挥你的优势。 Twitter 是一个典型的例子：99.99% 的推文在第一个小时/天/周/任何时间之后将永远不会被访问。这会在您的数据架构中开启各种有趣的优化可能性。
这只是冰山一角。我建议阅读一些基于列的 NoSQL 系统（例如 Cassandra）
【讨论】：