0

由于我是 MongoDB 的新手，我有很多关于模式设计的问题。出于学习原因，我想将我的关系模式转换为 MongoDB 模式，并希望尽可能多地从该模式中获利。

在我的规范化关系数据库中，模块和 Lecture_types 之间存在多对多的关系。

  • modules 表只有一个属性：name
  • Lecture_types 表具有以下属性：description、default_group_size
  • 连接表也有一个属性：小时

我的基本用例是：我想在模块的上下文中查看讲座类型，以便在模块中立即使用演讲类型。

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

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

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

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

先感谢您！

4

1 回答 1

0

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

谈到架构，它看起来不错。关于深度嵌套的东西，你不用担心，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 }
    },
    ....
    ....
  ]
}
于 2013-05-16T00:49:29.650 回答