代表具有属性的多对多关系的最“ mongo”方式是什么?
因此,例如:
MYSQL表
people => firstName, lastName, ...
people
firstName, lastName, ...
Movies => name, length ..
Movies
name, length ..
peopleMovies => movieId, personId, language, role
peopleMovies
movieId, personId, language, role
将人们嵌入电影中…?
在MongoDB中,我知道这样denormalize and embed做很好,但是我不想让embed人们看电影,从逻辑上讲这没有任何意义。因为人们不一定只属于电影。
denormalize and embed
embed
People并且Movies将两个单独的集合。 People=>嵌入[{movieId: 12, personId: 1, language: "English", role: "Main"} ...]
People
[{movieId: 12, personId: 1, language: "English", role: "Main"} ...]
Movies =>嵌入 [{movieId: 12, personId: 1, language: "English", role: "Main"} ...]
该解决方案的问题在于,当我们要role为特定对象更新人员时,movie我们需要运行两个更新查询以确保两个集合中的数据同步。
role
movie
我们还可以做一些与关系有关的事情,最后得到三个集合
People=> firstName, lastName, ... Movies=> name, length .. Castings=>movieId, personId, language, role
Castings
问题在于,由于MongoDB中缺少join语句,因此需要3 queries从人那里去->电影,反之亦然。
3 queries
这是我的问题,还有什么其他方式可以对此类事物进行建模MongoDB以及更多NoSQL方式。就提供的解决方案而言,在mongo的性能和约定方面哪一种是最好的。
MongoDB
NoSQL
流星的API在许多方面都鼓励使用扁平的关系文档,但是MongoDB是非关系数据存储。不幸的是,这种冲突留给开发人员解决。
模式结构和连接的概念是一个巨大的主题,需要在一个答案中进行介绍,因此我将尝试尽可能简洁。
假设您有评论并发布数据。考虑一下如果在帖子中嵌入评论会发生什么。
DDP处理文档。每当在同一帖子中添加新评论时,将发送所有评论。
allow和deny规则上的文件进行操作。期望相同的规则同时应用于帖子和评论可能是不合理的。
allow
deny
出版物在收藏方面往往更有意义。在上述情况下,我们无法轻易发布独立于其帖子的评论列表。
关系数据库存在是有充分理由的。其中之一是避免第二种解决方案固有的多重修改问题。
使用您的第三个解决方案。以我的经验,选择关系模型的原因远远超过了数据存储所施加的限制。当然,克服缺少联接的问题并不容易,但是这种痛苦很可能仅局限于少数几个发布功能。我强烈推荐以下资源:
如何在EventedMind上发布多对多关系。克里斯详细介绍了您的确切用例,但是他通过观察回调手动执行反应式联接,我不建议这样做。
Reactive从“ 发现流星百科全书”中加入了流星。这涵盖了有关如何以及为什么应进行反应式联接的基础知识。
《发现流星》中的非规范化章节。这涵盖了我上面提到的许多观点,还讨论了何时以及如何对某些数据进行非规范化。
您可以使用带有关系的发布来合并数据。替代软件包包括:智能发布,复合发布和简单发布。
如果您还需要其他更多信息,请在下面评论,我将更新我的答案。