mongodb - 子文档mongodb的动态大小

Question

我正在为我的 Web 应用程序使用 mongodb 和 mongoose。该网络应用程序用于游泳比赛的注册，每场比赛可以有 X 场比赛。我目前的数据结构:

{
  "_id": "1",
  "name": "Utmanaren",
  "location": "town",
  "startdate": "20150627",
  "enddate": "20150627"
  "race" : {
    "gender" : "m"
    "style" : "freestyle"
    "length" : "100"
  }
}

这样做我需要确定和定义每场比赛的比赛数量。我尝试过的一个解决方案是拥有一个单独的文档并拥有一个比赛所属比赛的 Id，如下所示。

{
  "belongsTOId" : "1"
  "gender" : "m"
  "style" : "freestyle"
  "length" : "100"
}
{
  "belongsTOId" : "1"
  "gender" : "f"
  "style" : "butterfly"
  "length" : "50"
}

有没有办法在使用 Mongodb 时创建和定义动态的种族数量作为子文档？

谢谢!

Answer 1

您基本上有两种建模数据结构的方法；您可以设计一个模式，您可以在其中引用或嵌入比赛文档。

让我们考虑以下映射游泳比赛和多种族关系的示例。如果您需要在另一个上下文中查看许多数据实体，这证明了嵌入优于引用的优势。在比赛和比赛数据之间的这种一对多关系中，比赛有多个比赛实体:

// db.competition schema
{
    "_id": 1,
    "name": "Utmanaren",
    "location": "town",
    "startdate": "20150627",
    "enddate": "20150627"
    "races": [
        {
            "gender" : "m"
            "style" : "freestyle"
            "length" : "100"
        },
        {           
            "gender" : "f"
            "style" : "butterfly"
            "length" : "50"
        }
    ]
}

借助嵌入式数据模型，您的应用程序只需一次查询即可检索到完整的游泳比赛信息。这种设计还有其他优点，其中之一就是数据局部性。由于 MongoDB 在磁盘上连续存储数据，将您需要的所有数据放在一个文档中可确保旋转磁盘花费更少的时间来寻找磁盘上的特定位置。嵌入式文档的另一个优点是写入数据的原子性和隔离性。为了说明这一点，假设您想删除具有值为“蝴蝶”的种族“风格”属性的比赛，这可以通过一个(原子)操作来完成:

db.competition.remove({"races.style": "butterfly"});

有关 MongoDB 中数据建模的更多详细信息，请阅读文档 Data Modeling Introduction ，特别是 Model One-to-Many Relationships with Embedded Documents

另一个设计选项是引用文档遵循规范化模式，其中竞赛文档包含对竞赛文档的引用:

// db.race schema
{
    "_id": 1,
    "competition_id": 1,
    "gender": "m",
    "style": "freestyle",
    "length": "100"
},
{
    "_id": 2,
    "competition_id": 1,
    "gender": "f",
    "style": "butterfly",
    "length": "50"
}

上述方法提高了执行查询的灵 active 。例如，要检索主要父实体 competition 的 id 为 1 的所有子种族文档将很简单，只需针对集合 race 创建一个查询:

db.race.find({"competiton_id": 1});

当您拥有非常不可预测的一对多关系时，上述使用文档引用方法的规范化模式也有优势。如果每个给定的 比赛 有成百上千个 race 文件，嵌入选项在空间限制方面有很多挫折，因为文件越大，越多它使用的 RAM 和 MongoDB 文档的硬大小限制为 16MB。

如果您的应用程序频繁检索包含比赛信息的比赛数据，那么您的应用程序需要发出多个查询来解析引用。

一般的经验法则是，如果您的应用程序的查询模式众所周知并且数据往往只能以一种方式访问​​，那么嵌入式方法会很有效。如果您的应用程序以多种方式查询数据，或者您无法预测数据查询模式，则更规范化的文档引用模型将适用于这种情况。

引用:

MongoDB Applied Design Patterns: Practical Use Cases with the Leading NoSQL Database By Rick Copeland