Question

我们正在编写一个应用程序，其中我们有多个项目＆＃39;。每个＆＃39;项目＆＃39;有多个董事会＆＃39;每个董事会＆＃39;有自己的一套评论＆＃39;。在MongoDB中构建它的推荐方法是什么？

= Option I (nested collection)
  -Project
    |
    |----- Board
             |
             |----- Comments


= Option II (flattened collection)
  -Project
    |
    |----- Board
    |
    |----- Comment
              |-----Board_ID


= Option III (independent collections)
  -Project

  - Boards
      |-----Project_ID

  - Comments
      |-----Board_ID

有10,000个项目。每个项目有5个板，因此总板数为50,000。每个董事会有20条评论，因此总评论为1,000,000。一次只能在应用程序中打开一个项目和一个板。

因此，如果我们选择选项I，那么就可以获得相关的评论＆＃39;对于特定的项目/板组合，我们将只需查询/解析20条评论。但是，如果我选择选项III，那么，要获得相关的评论＆＃39;对于给定的项目/板组合，我们将不得不查询/解析1,000,000条评论。因此，理论上，选项I听起来更快，更有效。但是，选项I使用嵌套集合：嵌套集合是否有任何不利之处？是否有任何理由不在MongoDB中使用嵌套集合，例如Option I？

MongoDB专家：针对此类案例的推荐做法是什么选项（I，II或III）？

Answer 1

最重要的问题可能是：你一起读写什么？

一次只能在应用程序中打开一个项目和一个板。

所以基本上1个项目及其20条评论主要是一起读写的？然后，我将它们存储在一个文档中（嵌入式comments），并将projects集合指向boards集合。

背景：

即使您从文档中读取了单个属性，也始终从磁盘中获取整个文档并将其加载到RAM中。即使您将查询限制为单个属性，也可以加载它 - 您只是不会通过网络发送它。
由于没有（多文档）事务，所以将事物放入一个您想要原子写入的文档中。
避免增长文档，因为一个文档需要作为单个块存储在磁盘上，并且移动成本很高。要么预先分配值（如果可能），要么为以后要添加的内容使用单独的文档。

MongoDB架构：嵌套，展平或独立集合？

1 个答案: