MongoDB 嵌套集合与单独集合

use*_*616 1 javascript database non-relational-database mongodb

我有一个与数据库相关的一般问题。它更具体地说明了如何处理关于 MongoDB 的集合。

假设我有一个 Parent 集合。然后我有一些除了父级之外的子级集合。它们每个都有单独的模式。目前,它们作为单独的集合存在于数据库中。

我通过将 parentId 属性添加到每个子文档来处理链接。

IE

Some_Child = {
        "parentId" : "some_id",
         rest_of_schema
  } 
Run Code Online (Sandbox Code Playgroud)

这似乎工作得很好。但是,我注意到我现在每次需要 Child 数据时都必须处理两个集合。这会导致更多的代码。即多次订阅,每次我只想对 Child 做一些事情时,都会调用 DB 调用。

关于以这种方式构建数据与在每个父文档上仅拥有一组 Childs 相比,您有什么想法?

IE

 Some_Parent = {
        "Childs" : [
                         {child1},
                         {child2},
                         {childN}
],
        Rest_Of_Schema
       }
Run Code Online (Sandbox Code Playgroud)

我对此的担忧是它是面向未来的。假设如果 Child 需要更多的数据和功能......那么父文档最终可能会变得非常大和混乱。此外,一般来说,抽象出这两个集合可能会更清晰。

通常,(在 RDMS 中),我什至不会考虑使用选项 #2。所以我只是想知道这是否是文档存储、MongoDB(以及一般的非关系 DBMS)的可接受模式。

任何见解?

Emi*_*uch 5

只要保证每个父级的子级数量不会很高,您绝对可以使用选项 #2,因为您不想冒险达到 16MB 的文档大小限制。

在 Mongo 中,一对多关系可以分为三种不同的实现(各有利弊):

  1. 一对一:将子文档嵌入到父文档中可能是最好的方法。
  2. 一对多:将子文档的 ID 列表保存在父文档的数组中。当链接文档的数量很大但不是特别大时有效。
  3. one-tomillions:在子文档中保留父 ID。这适用于任意数量的子文档。

使用哪一个取决于许多因素,例如最可能的关系导航方式是什么,是否需要独立于父文档查找子文档等。