6 Rules of Thumb for MongoDB Schema Design: Part 1

作者 William Zola， Lead Technical Support Engineer at MongoDB

“我有很多使用SQL的经验，但在对于 MongoDB 还只是一个初学者。我应该如何为 一对多 的关系建模呢？” 这是我工作时从 MongoDB 用户收到很常见问题。

对于这个问题我没办法给出一个简短的答案，因为方法有很多，不止某一种。MongoDB 有一个丰富而细微的语汇去表达在SQL中被扁平化为术语 “1 to N ” 的内容。

这个话题有很多可以讲的，我将其分成三个部分。

第一个部分，我会谈三个基础的方法去建立 1对多 关系模型。

第二个话题，会涉及复杂的 Shema 设计，包括反范式化和双向引用。

最后一部分，我会回顾各种各样的选择，并提供一些在考虑构建一个 1对多 关系模型时的建议。

许多初学者认为 MongoDB 中构建 1对多关系模型的唯一方法是在父文档中嵌入一个子文档数组，但这个是不对的。你可以嵌入一个文档，但不意味着你应该嵌入一个文档。

在设计 MongoDB Shema 时，你需要从一个你在使用 SQL 时从来没想过的问题开始：这个关系的基数 (cardinality，指 N 端的数据规模 ) 是怎么样的？简言之：你需要更加细微地表述你的 1对多 关系：它是 1对少，1对很多，还是 1 对非常多？根据它是哪种，你可以去选择不同的方式对关系建模。

基础知识：1对少建模

一个人的地址可以作为 1对少的示例。这个是一个关于内嵌子文档的好案例 ——在 Person 对象中嵌入一组 address 文档：


> db.person.findOne()
{
  name: 'Kate Monster',
  ssn: '123-456-7890',
  addresses : [
     { street: '123 Sesame St', city: 'Anytown', cc: 'USA' },
     { street: '123 Avenue Q', city: 'New York', cc: 'USA' }
  ]
}

这种设计具有内嵌子文档的所有优缺点。主要的优点是不必执行一个单独查询来获取内嵌的资料，主要的缺点则是内嵌的资料没办法作为一个单独的实体进行访问。

例如，你在为一个任务追踪系统建模，每一个 Person 都会有很多任务分配到他们。在Person 文档中的内嵌任务会让如显示由于明天到期的任务这样的查询变得比其实际需要的更加困难。对于这种案例，我会在下一个部分提供一个更合适的设计。

基础知识：1对很多建模

替换零部件订购系统中产品的零部件可以作为 1对多 的示例。每一个产品可能都有几百个替换李建，但绝不会超过几千个左右（所有这些不同尺寸的螺栓，垫圈和垫圈加起来）。这是一个很好的参考案例，你可以将零件的 ObjectID 内嵌到产品的问题中。（这个示例中，我使用2字节的 ObjectID，因为它们更易于阅读：实际代码将使用12字节的 ObjectID ）

每一个零部件 _( parts )_会有它们的自己的文档：

> db.parts.findOne()
{
    _id : ObjectID('AAAA'),
    partno : '123-aff-456',
    name : '#4 grommet',
    qty: 94,
    cost: 0.94,
    price: 3.99
}

每一个产品 _( products )_也会有它们自己的文档，其文档中还会所以包含组成产品的 parts 的 ObjectID 数组：

> db.products.findOne()
{
    name : 'left-handed smoke shifter',
    manufacturer : 'Acme Corp',
    catalog_number: 1234,
    parts : [     // array of references to Part documents
        ObjectID('AAAA'),    // reference to the #4 grommet above
        ObjectID('F17C'),    // reference to a different Part
        ObjectID('D2AA'),
        // etc
    ]
}

然后，您再使用应用程序级联接来检索特定产品的零件：

 // Fetch the Product document identified by this catalog number
> product = db.products.findOne({catalog_number: 1234});
   // Fetch all the Parts that are linked to this Product
> product_parts = db.parts.find({_id: { $in : product.parts } } ).toArray() ;

为了操作更加高效，你可能还需要为products.catalog_number 建立索引。注意parts._id一定有索引的，因此查询 parts 会很快。

这种风格的引用能与内嵌文档的优缺点起到互补的左右。每一个零件都是一个单独的文档，因此很容易对他们做独立的查询和更新。使用这个 Schema 也需要一点妥协，就是在获取查询零部件详细信息时需要在再做一次查询。（但先保留这个问题，直到我们进入 part 2 - 反范式化）。

作为一个额外的好处，这种 Schema 允许你在多个产品中使用不同的零件，所以你的 1对多 Schema 就变成了多对多的 Schema 不需要任何关联表了。

基础知识：1对非常多建模

从不同机器上收集日志信息的事件日志系统可以作为 1对很多 的示例。任何给定 host 可以生产超过16Mb 的文档大小，即使你的的数组中村咋都是 ObjectID 。这是一个 “父引用”经典案例 — 你可有一个host 文档，并且在每一个日志信息文档中存储这个 Host 的 ObjectID 。

> db.hosts.findOne()
{
    _id : ObjectID('AAAB'),
    name : 'goofy.example.com',
    ipaddr : '127.66.66.66'
}

>db.logmsg.findOne()
{
    time : ISODate("2014-03-28T09:42:41.382Z"),
    message : 'cpu is on fire!',
    host: ObjectID('AAAB')       // Reference to the Host document
}

你可以用一个有一点点不同的应用级别的联合查询得到一个host最近5000条Messages：

  // find the parent ‘host’ document
> host = db.hosts.findOne({ipaddr : '127.66.66.66'});  // assumes unique index
   // find the most recent 5000 log message documents linked to that host
> last_5k_msg = db.logmsg.find({host: host._id}).sort({time : -1}).limit(5000).toArray()

回顾

如此可见，即使在这个基础的级别，设计 MongoDB Schema 时比设计一个对比的关系性的 Schema要思考的更多。有以下两个的因素需要考虑：

1对多中"多"端的实体需要独立存在吗？
这个关系的基数是什么样的：1对少，1对很多，还是1对非常多？

基于这些因素，你可以选择三个基本的 1对多 Schema 设计：

如果基数是 1对少并且不需要从父对象的上下文之外访问内嵌的对象，则直接内嵌N端；
如果基数为一对多或者 N 端对象因故需要独立存在，则内嵌 N 端对象的引用数组。
如果基数为一对很多，则在 N 端对象中引用 1端对象。

下一次，我们将了解如何使用双向关系和非规范化来增强这些基础的 Schema 性能。

写在后面：

最开始是在这篇文章 MongoDB数据库设计中6条重要的经验法则里看到的，但是因为排版不是很容易阅读，因此我直接阅读了原文，并自己试着从新翻译排版，部分术语的理解也参考了 MongoDB数据库设计中6条重要的经验法则。

文章虽然已经比较久了，但对我才开始使用的 MongoDB 的初学者来讲，里面的知识点还是非常有价值的。后面还有两篇，会接着看完并翻译发表。希望对看到的人也有所帮助。