小编典典

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

mysql

代表具有属性的多对多关系的最“ 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的性能和约定方面哪一种是最好的。


阅读 543

收藏
2020-05-17

共1个答案

小编典典

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

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

选择关系模型的原因

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

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

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

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

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

选择嵌入式模型的原因

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

推荐建议

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

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

2020-05-17