【问题标题】:MongoDB Nested vs Separate CollectionsMongoDB 嵌套集合与单独集合
【发布时间】:2020-01-02 15:45:03
【问题描述】:

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

假设我有一个 Parent 集合。然后,我有一些属于 Parent 的 Child 集合。它们每个都有单独的模式。目前,它们作为单独的集合存在于数据库中。

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

Some_Child = {
        "parentId" : "some_id",
         rest_of_schema
  } 

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

对于以这种方式构建数据与在每个父文档上仅包含一组子对象有何想法?

I.E.

 Some_Parent = {
        "Childs" : [
                         {child1},
                         {child2},
                         {childN}
],
        Rest_Of_Schema
       }

我对此的担忧是它不会过时。假设 Child 需要更多的数据和功能……那么 Parent 文档最终可能会变得非常庞大和混乱。此外,一般而言,抽象出这两个集合可能会更简洁。

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

有什么见解吗?

【问题讨论】:

    标签: javascript database mongodb non-relational-database


    【解决方案1】:

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

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

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

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

    【讨论】:

      猜你喜欢
      • 2013-03-28
      • 1970-01-01
      • 2015-09-03
      • 2016-12-14
      • 1970-01-01
      • 2021-12-05
      • 2014-11-08
      • 1970-01-01
      • 2014-05-27
      相关资源
      最近更新 更多