表示MongoDB中具有属性的多对多关系的最佳模型

  • Z时代
  • 2024-01-10
  • 分类：问答

代表具有属性的多对多关系的最“ mongo”方式是什么？

因此，例如：

介绍

MYSQL表

people => firstName, lastName, ...

Movies => name, length ..

peopleMovies => movieId, personId, language, role

解决方案1

将人们嵌入电影中…？

在MongoDB中，我知道这样denormalize and

embed做很好，但是我不想让embed人们看电影，从逻辑上讲这没有任何意义。因为人们不一定只属于电影。

解决方案2

People并且Movies将两个单独的集合。 People=>嵌入[{movieId: 12, personId: 1, language:

"English", role: "Main"} ...]

Movies =>嵌入 [{movieId: 12, personId: 1, language: "English", role: "Main"}

...]

该解决方案的问题在于，当我们要role为特定对象更新人员时，movie我们需要运行两个更新查询以确保两个集合中的数据同步。

解决方案3

我们还可以做一些与关系有关的事情，最后得到三个集合

People=> firstName, lastName, ...Movies=> name, length ..

Castings=>movieId, personId, language, role

问题在于，由于MongoDB中缺少join语句，因此需要3 queries从人那里去->电影，反之亦然。

这是我的问题，还有什么其他方式可以对此类事物进行建模MongoDB以及更多NoSQL方式。就提供的解决方案而言，在mongo的性能和约定方面哪一种是最好的。

回答：

流星的API在许多方面都鼓励使用扁平的关系文档，但是MongoDB是非关系数据存储。不幸的是，这种冲突留给开发人员解决。

模式结构和连接的概念是一个巨大的主题，需要在一个答案中进行介绍，因此我将尝试尽可能简洁。

选择关系模型的原因

假设您有评论并发布数据。考虑一下如果在帖子中嵌入评论会发生什么。

  • DDP处理文档。每当在同一帖子中添加新评论时，将发送所有评论。

  • allow和deny规则上的文件进行操作。期望相同的规则同时应用于帖子和评论可能是不合理的。

  • 出版物在方面往往更有意义。在上述情况下，我们无法轻易发布独立于其帖子的评论列表。

  • 关系数据库存在是有充分理由的。其中之一是避免第二种解决方案固有的多重修改问题。

选择嵌入式模型的原因

  • MongoDB本身不支持联接，并且没有生成响应联接的核心程序包。

推荐建议

使用您的第三个解决方案。以我的经验，选择关系模型的原因远远超过了数据存储所施加的限制。当然，克服缺少联接的问题并不容易，但是这种痛苦很可能仅局限于少数几个发布功能。我强烈推荐以下资源：

  • 如何在EventedMind上发布多对多关系。克里斯详细介绍了您的确切用例，但是他通过观察回调手动执行反应式联接，我不建议这样做。

  • Reactive从“ 发现流星百科全书”中加入了流星。这涵盖了有关如何以及为什么应进行反应式联接的基础知识。

  • 《发现流星》中的非规范化章节。这涵盖了我上面提到的许多观点，还讨论了何时以及如何对某些数据进行非规范化。

  • 您可以使用带有关系的发布来合并数据。替代软件包包括：智能发布，复合发布和简单发布。

如果您还需要其他更多信息，请在下面评论，我将更新我的答案。

以上是 表示MongoDB中具有属性的多对多关系的最佳模型 的全部内容， 来源链接： utcz.com/qa/419612.html

回到顶部