我有一个 db 架构，它看起来像传统的 Post、Comments 架构 s.t。帖子有很多评论。
有时我需要在大量 cmets 中搜索特定字段，并且根本不想要这些帖子。所以像 db.posts.find({$where this.comments.field == blah}) 这样返回帖子而不是 cmets 的东西不好。
我现在做的也不好。我在 Posts 集合中有一个名为 cmets 的字段，它保存 Posts 中 Comments 的 _ids。这将它们视为关系数据库。
相反，我想做的是为每个帖子和评论保留一个集合。然后，我不想将 Comments 数据嵌入 Posts 并尝试使该数据与 Comments 集合数据保持同步，而是将 Comment 本身嵌入 Posts。我认为这就像有一个子系列。这是标准吗？这样做有什么坏处？我看到的大多数讨论都是针对嵌入文档而不是嵌入集合。
【问题讨论】：
标签： mongodb collections
相反，我想做的是为每个帖子和评论保留一个集合。
有道理
我想在帖子中嵌入评论本身。
这和你之前说的矛盾
喜欢有一个子系列。这是标准吗？ [...] 我看到的大多数讨论 [...] 都是针对嵌入文档而不是嵌入集合。
那是因为“嵌入集合”不存在，我不确定它是否真的有意义（对我来说听起来像是物化视图）
根据您在问题中的陈述，我认为两个单独的集合最有意义（就像它们通常用于帖子和 cmets 的原型示例一样） - 这已经进行了很长时间的讨论（an in short）。然后，要链接它们，请使用良好的关系方式：
Post { _id : ObjectId("..."), ... }
Comment { _id : ObjectId("..."), postId : ObjectId("..."), ... }
【讨论】：
db.comments.find() 和db.comments.find({"postId" : somePostId}) 有什么区别？这些不是“嵌入式集合”应该具备的功能吗？
如果您不必在没有父文档的情况下处理子文档，那么在文档中包含子文档会很好。
在您的情况下，如果您不使用 cmets 做任何事情，最好将 cmets 嵌入到每个帖子中。如果您想找到一些最新的 cmets 或特定用户的一些 cmets，最好有两个集合。即使它看起来与你有关。
【讨论】：
comments 类似于 { _id, title, comments[{_id, text}, {_id, text} ...]}
_id 非常烦人 - _id 不是嵌入式数组中的保留名称 - 它不是默认（唯一）键，不是主键，可以修改。此外，数组没有集合语义，它们必须以非常不同的方式工作，所以请不要为已经存在的过多令人讨厌的错误信息做出贡献。没有“子集合”