Question

由于我是MongoDB的新手，因此我对模式设计提出了很多疑问。出于学习原因，我想将我的关系模式转换为MongoDB-Schema，并希望尽可能从模式中获利。

在我的规范化关系数据库中，我在模块和讲座类型之间建立了多对多的关系。

modules表只有一个属性：name
lecture_types表具有以下属性：description， default_group_size
连接表还有一个属性：hours

我的基本用例是：我希望在模块的上下文中看到讲座类型，以便我在一个模块中立即提供讲座类型。

但与此同时，我希望系统中列出所有讲座类型。例如，我想在视图中实现一个下拉列表来创建一个新模块，显示所有可用的讲座类型。

由于我基本上想要访问我的模块，包括讲座类型，我想到了一个非常非规范化的模式文档设计，如下所示：

{
  name: "...",
  lecture_types: [
    { 
      hours: 2,
      lecture_type: { description: "...", default_group_size: 50 }
    },
    { 
      hours: 3,
      lecture_type: { description: "...", default_group_size: 20 }
    }
  ]
}

这是个好主意吗？描述和默认组大小很少改变，但是我不喜欢一次又一次地存储相同的信息。我也不确定深度嵌套的“模拟”连接表。你有其他选择吗？

提前谢谢！

Answer 1

总是进行非规范化以将相关数据保持在具有其优点和缺点的相同位置。优点是查询速度，缺点是磁盘空间大，查询更新困难。

谈到架构，它看起来很好。关于深层嵌套的东西，你不用担心，mongoDB在这部分工作正常。如果您担心“描述”可能太长并且在同一文档中存储多次，那么您可以将所有“描述”放在顶层，并引用它们。但您必须检查您的查询要求（即您如何更新此文档）

如果可能的话，尝试在mongo中使用小键，因为它们在每个文档中都被复制。在应用程序层中，您可以为这些小键使用更好的名称。

{
  name: "...",
  ref : {
      1 : 'description1',
      2 : 'description2'
  },
  lecture_types: [
    { 
      hours: 2,
      lecture_type: { description: 1, default_group_size: 50 }
    },
    { 
      hours: 3,
      lecture_type: { description: 2, default_group_size: 20 }
    },
    { 
      hours: 2,
      lecture_type: { description: 1, default_group_size: 40 }
    },
    ....
    ....
  ]
}

具有额外属性的MongoDB多对多

1 个答案: