流星的API在许多方面都鼓励使用扁平的关系文档，但是MongoDB是非关系数据存储。不幸的是，这种冲突留给开发人员解决。
模式结构和连接的概念是一个巨大的主题，需要在一个答案中进行介绍，因此我将尝试尽可能简洁。
选择关系模型的原因
假设您有评论并发布数据。考虑一下如果在帖子中嵌入评论会发生什么。
DDP处理文档。每当在同一帖子中添加新评论时，将发送所有评论。
allow
和deny
规则上的文件进行操作。期望相同的规则同时应用于帖子和评论可能是不合理的。出版物在收藏方面往往更有意义。在上述情况下，我们无法轻易发布独立于其帖子的评论列表。
关系数据库存在是有充分理由的。其中之一是避免第二种解决方案固有的多重修改问题。
选择嵌入式模型的原因
- MongoDB本身不支持联接，并且没有生成响应联接的核心程序包。
推荐建议
使用您的第三个解决方案。以我的经验，选择关系模型的原因远远超过了数据存储所施加的限制。当然，克服缺少联接的问题并不容易，但是这种痛苦很可能仅局限于少数几个发布功能。我强烈推荐以下资源：
如何在EventedMind上发布多对多关系。克里斯详细介绍了您的确切用例，但是他通过观察回调手动执行反应式联接，我不建议这样做。
Reactive从“ 发现流星百科全书”中加入了流星。这涵盖了有关如何以及为什么应进行反应式联接的基础知识。
《发现流星》中的非规范化章节。这涵盖了我上面提到的许多观点，还讨论了何时以及如何对某些数据进行非规范化。
您可以使用带有关系的发布来合并数据。替代软件包包括：智能发布，复合发布和简单发布。
如果您还需要其他更多信息，请在下面评论，我将更新我的答案。
