meteorjs 应用程序的 MongoDB 模型设计答案

【问题标题】：MongoDB model design for meteorjs appmeteorjs 应用程序的 MongoDB 模型设计
【发布时间】：2015-01-04 21:48:18
【问题描述】：

我更习惯于关系数据库，并且很难考虑如何在 mongoDB 中设计我的数据库，并且在考虑到 meteorjs 数据库设计的一些特殊考虑时更加不清楚，我在哪里了解您通常更喜欢单独的集合而不是嵌入的文档/数据，以便更好地利用您从集合中获得的一些好处。

假设我想跟踪学生在高中的学习进度。他们需要在每个学年完成某些必修课才能升读下一年（大一、大二、大三、大四），还可以完成一些选修课。我需要跟踪学生何时完成每个要求或选修课。每年的要求可能略有不同，但我需要记住，例如，Johnny 完成了两年前存在的所有新生要求。

所以我有：

学生要求选修课年级（初等）年

大多数情况下，我正在尝试考虑如何设置要求。在关系数据库中，我有一个要求表，其中包含 className、grade 和 year，以及一个 student_requirements 表，用于在学生完成每个要求时对其进行跟踪。但我正在考虑在 MongoDB/meteorjs 中，我会为每个年级/级别创建一个模型，该模型与一个 studentID 一起存储，并最初为每个要求使用错误值进行实例化，例如：

{
    student: [studentID],
    class: 'freshman'
    year: 2014,
    requirements: {
        class1: false,
        class2: false
    }
}

当学生完成一个要求时，它会更新如下：

{
    student: [studentID],
    class: 'freshman'
    year: 2014,
    requirements: {
        class1: false,
        class2: [completionDateTime]
    }
}

因此，通过这种方式，每个学生将收集四个Requirements 文档，这些文档在某种程度上取决于它们的初始实例化值。而不是每个年级/年的实际要求存在于数据库中，它们本质上将存在于代码本身中。

我希望能够支持的一些操作是同时标记一组学生的要求，并显示用户/要求网格以查看谁需要什么。

这听起来合理吗？还是有更好的方法来解决这个问题？我在这个应用程序中很早，希望避免把自己画到一个角落里。任何帮助建议表示赞赏。谢谢！ :-)

【问题讨论】：

标签： mongodb meteor

【解决方案1】：

目前我也在考虑我的应用程序数据设计。我已经阅读了 MongoDB 手册中的示例

查找 MongoDB 手动数据模型设计 - docs.mongodb.org/manual/core/data-model-design/

这里 -> MongoDB 手动一对一关系 - docs.mongodb.org/manual/tutorial/model-embedded-one-to-one-relationships-between-documents/

（抱歉，我目前不能在答案中发布多个链接）

他们说：

一般来说，在以下情况下使用嵌入式数据模型：

实体之间存在“包含”关系。
实体之间存在一对多关系。在这些关系中，“许多”或子文档始终与“一个”或父文档一起出现或在其上下文中查看。

规范化方法在一个文档中使用对另一个文档的引用。就像在Meteor.js book 中一样。他们创建了一个显示帖子的网络应用程序，每个帖子都有一组 cmets。他们使用两个集合，posts 和 cmets。添加评论时，它与 post_id 一起提交。

因此，在您的示例中，您有一个学生集合。每个学生都必须满足要求吗？每个学生都有自己的要求，就像一个职位有自己的cmets？

然后我会像他们在书中那样处理它。有两个系列。我认为这应该是规范化的方法，而不是嵌入式。

我自己也有点困惑，所以如果我的回答有道理，也许你可以告诉我。

也许你也可以帮助我？我正在尝试制作一个管理跳蚤市场的应用程序。

应用的用户创建事件。

活动的创建者邀请用户担任该活动的收银员。

用户创建他们想要销售的东西的列表。最大限度。每个事件的列表/卖家数量。最大限度。列表中的位置数 (25/50)。

收银员在活动中输入这些列表的位置，以跟踪所售商品。

活动创建者为每个列表中的已售商品开具账单，然后分发钱。

我很困惑如何设置数据设计。我需要事件和列表。我是使用规范化方法还是嵌入式方法？

编辑：

阅读 percona.com/blog/2013/08/01/schema-design-in-mongodb-vs-schema-design-in-mysql/ 后，我发现以下建议：

如果您 99% 的时间都在阅读人员信息，那么拥有 2 个单独的集合可能是一个很好的解决方案：它可以避免将几乎从未使用过的数据（护照信息）保存在内存中，以及当您需要获取特定人员的所有信息时，在应用程序中加入可能是可以接受的。
如果您想在一个屏幕上显示人名并在另一个屏幕上显示护照信息，也是如此。
但是，如果您想显示给定人员的所有信息，则将所有信息存储在同一个集合中（使用嵌入或扁平结构）可能是最佳解决方案

【讨论】：