一对一 关系表示两个不同对象之间的关联，其中一个对象仅与另一个种类的一个对象相连。

继续使用前一节的学生示例，每个学生在任何给定时间点都只有一张有效的学生身份证。一张卡片永远不会属于多个学生，也没有学生可以拥有多张身份证。如果您将所有这些数据存储在关系型数据库中，将学生记录和身份证记录存储在通过引用关联的单独表中来建模学生与其身份证之间的关系是合理的。

在文档数据库中表示此类关系的一种常见方法是使用嵌入文档。例如，以下文档描述了名为 Sammy 的学生及其学生身份证：

{
    "_id": ObjectId("612d1e835ebee16872a109a4"),
    "first_name": "Sammy",
    "last_name": "Shark",
    "id_card": {
        "number": "123-1234-123",
        "issued_on": ISODate("2020-01-23"),
        "expires_on": ISODate("2020-01-23")
    }
}

请注意，此示例文档的 id_card 字段不是单个值，而是包含一个嵌入文档，表示学生的身份证，由身份证号码、发卡日期和过期日期描述。身份证本质上成为了描述学生 Sammy 的文档的一部分，尽管在现实生活中它是一个独立的对象。通常，像这样构建文档模式，以便通过单个查询检索所有相关信息，是一个明智的选择。

如果您遇到将一种对象与另一种类型的多个对象连接的关系，例如学生的电子邮件地址、他们参加的课程或他们在学生会留言板上发布的消息，情况就会变得不那么简单。在接下来的几个指南中，您将使用这些数据示例来学习处理一对多和多对多关系的不同方法。

当一个类型的对象与另一个类型的多个对象相关联时，可以将其描述为一对多关系。一个学生可以有多个电子邮件地址，一辆汽车可以有众多零件，或者一个购物订单可以包含多个商品。这些例子都代表一对多关系。

虽然在文档数据库中最常见的一对一关系的表示方式是通过嵌入文档，但在文档模式中建模一对多关系有几种方式。在考虑如何最佳建模这些关系时，有三个给定关系的属性需要考虑：

• 基数：基数是给定集合中单个元素数量的度量。例如，如果一个班级有 30 名学生，可以说该班级的基数为 30。在一对多关系中，基数在每个案例中可能不同。一个学生可能只有一个电子邮件地址，也可能有多个。他们可能只注册了几个班级，也可能日程完全满员。在一对多关系中，“多”的规模会影响数据建模方式。
• 独立访问：有些相关数据很少（如果有的话）会独立于主对象访问。例如，单独检索一个学生的电子邮件地址而不带其他学生详细信息的情况可能不常见。另一方面，大学的课程可能需要独立访问和更新，而不管注册参加的学生是谁。是否会单独访问相关文档也会影响数据建模方式。
• 数据之间的关系是否严格为一一对多关系：考虑一个示例学生在大学参加的课程。从学生的角度来看，他们可以参加多个课程。表面上看，这似乎是一对多关系。然而，大学课程很少只有一个学生参加；更常见的是多个学生参加同一门课。在这种情况下，所讨论的关系实际上不是一对多关系，而是一对多关系，因此建模这种关系的方式与一对多关系不同。

想象一下你正在决定如何存储学生的电子邮件地址。每个学生可以有多个电子邮件地址，例如一个用于工作、一个用于个人使用，以及一个由大学提供。表示单个电子邮件地址的文档可能采用以下形式：

{
    "email": "sammy@example.com",
    "type": "work"
}

就基数而言，每个学生只有少数几个电子邮件地址，因为学生不太可能有数十个——更不用说数百个——电子邮件地址。因此，这种关系可以描述为一对少关系，这是将电子邮件地址直接嵌入学生文档中并一起存储的强有力理由。你不会面临电子邮件地址列表无限增长的风险，这会导致文档变大且使用效率低下。

关于独立访问，电子邮件地址很可能不会独立于学生访问。因此，没有明确理由将它们作为单独的文档存储在单独的 collection 中。这是将它们嵌入学生文档中的另一个强有力理由。

最后需要考虑的是，这种关系是否真的是对多关系而不是多对多关系。因为一个电子邮件地址属于单个人，因此合理地将这种关系描述为一对多关系（或者更准确地说，一对少关系）而不是多对多关系。

这三个假设表明，将学生的各种电子邮件地址嵌入描述学生本身的同一文档中是存储此类数据的良好选择。带有嵌入电子邮件地址的示例学生文档可能具有以下结构：

{
    "_id": ObjectId("612d1e835ebee16872a109a4"),
    "first_name": "Sammy",
    "last_name": "Shark",
    "emails": [
        {
            "email": "sammy@example.com",
            "type": "work"
        },
        {
            "email": "sammy@example.com",
            "type": "home"
        }
    ]
}

使用这种结构，每次检索学生的文档时，都会在同一读操作中检索嵌入的电子邮件地址。

如果你建模一对少类型的关系，其中相关文档不需要独立访问，像这样直接嵌入文档通常是可取的，因为这可以减少 schema 的复杂性。

不过，如前所述，像这样嵌入文档并不总是最优解决方案。下一节将详细说明在某些场景中为什么会这样，并概述如何使用子引用作为在文档数据库中表示关系的替代方式。

学生与其电子邮件地址之间的关系性质决定了在文档数据库中如何最好地建模这种关系。这与学生及其所修课程之间的关系存在一些差异，因此建模学生与其课程关系的方式也将不同。

描述学生所修一门课程的单个文档可以采用如下结构：

{
    "name": "Physics 101",
    "department": "Department of Physics",
    "points": 7
}

假设你从一开始就决定使用嵌入文档来存储每个学生的课程信息，如以下示例：

{
    "_id": ObjectId("612d1e835ebee16872a109a4"),
    "first_name": "Sammy",
    "last_name": "Shark",
    "emails": [
        {
            "email": "sammy@example.com",
            "type": "work"
        },
        {
            "email": "sammy@example.com",
            "type": "home"
        }
    ],
    "courses": [
        {
            "name": "Physics 101",
            "department": "Department of Physics",
            "points": 7
        },
        {
            "name": "Introduction to Cloud Computing",
            "department": "Department of Computer Science",
            "points": 4
        }
    ]
}

这是一个完全有效的 MongoDB 文档，并且完全可以满足需求，但请考虑前一指南中介绍的三种关系属性。

第一种是 cardinality（基数）。一个学生通常只会维护少数几个电子邮件地址，但他们在学习期间可能会修读多门课程。经过几年的学习后，学生可能参与了数十门课程。而且，他们会与其他许多学生一起修读这些课程，这些学生也在多年学习期间修读自己的课程集合。

如果你像前面的示例一样嵌入每门课程，学生的文档将很快变得难以管理。基数越高，嵌入文档的方法就越不具吸引力。

第二种考虑因素是 independent access（独立访问）。与电子邮件地址不同，可以合理假设大学课程信息有时需要独立检索。例如，有人需要获取可用课程信息来准备营销手册。此外，课程信息可能会随着时间更新：授课教授可能变更、课程时间表可能波动，或者先修要求可能需要更新。

如果你将课程作为嵌入在学生文档中的文档存储，检索大学提供的所有课程列表将变得麻烦。而且，每次课程需要更新时，你都需要遍历所有学生记录并到处更新课程信息。这两个都是将课程单独存储而不完全嵌入的充分理由。

第三种考虑因素是学生与大学课程之间的关系实际上是一对多还是多对多。在这种情况下，后者更准确，因为多于一个学生可以修读每门课程。这种关系的基数和独立访问方面建议不要嵌入每门课程文档，主要出于访问和更新便利等实际原因。考虑到课程与学生之间多对多的关系，将课程文档存储在单独的 collection 中并为其分配唯一的标识符可能更合理。

这个单独 collection 中表示课程的文档可能具有如下结构：

{
    "_id": ObjectId("61741c9cbc9ec583c836170a"),
    "name": "Physics 101",
    "department": "Department of Physics",
    "points": 7
},
{
    "_id": ObjectId("61741c9cbc9ec583c836170b"),
    "name": "Introduction to Cloud Computing",
    "department": "Department of Computer Science",
    "points": 4
}

如果你决定这样存储课程信息，你需要找到一种方法将学生与这些课程连接起来，以便知道哪些学生修读了哪些课程。在相关对象数量不是特别大的情况下，尤其是多对多关系中，一种常见方法是使用 child references（子引用）。

使用子引用时，学生的文档将在嵌入数组中引用学生所修课程的 object identifiers，如以下示例：

{
    "_id": ObjectId("612d1e835ebee16872a109a4"),
    "first_name": "Sammy",
    "last_name": "Shark",
    "emails": [
        {
            "email": "sammy@example.com",
            "type": "work"
        },
        {
            "email": "sammy@example.com",
            "type": "home"
        }
    ],
    "courses": [
        ObjectId("61741c9cbc9ec583c836170a"),
        ObjectId("61741c9cbc9ec583c836170b")
    ]
}

注意，这个示例文档仍然有一个 courses 字段，它也是一个数组，但与早期示例不同，不是嵌入完整的课程文档，而是只嵌入引用单独 collection 中课程文档的 identifiers。现在，在检索学生文档时，课程不会立即可用，需要单独查询。另一方面，可以立即知道要检索哪些课程。而且，如果任何课程的详细信息需要更新，只需更改课程文档本身。学生与其课程之间的所有引用都将保持有效。

如果你建模一对多关系，其中相关文档的数量在合理范围内且相关文档需要独立访问，优先将相关文档单独存储，并嵌入子引用来连接它们。

现在你已经学会了如何使用子引用表示不同类型数据之间的关系，本指南将介绍一个反向概念：parent references（父引用）。

当相关对象数量太多无法直接嵌入父文档中，但数量仍在已知范围内时，使用子引用效果很好。然而，有些情况下关联文档的数量可能是无界的，并且会随着时间持续增长。

例如，想象大学的学生会有一个留言板，任何学生都可以发布他们想要的任何消息，包括课程问题、旅行故事、工作招聘、学习资料，或者只是自由聊天。这个示例中的一条示例消息由主题和消息正文组成：

{
    "_id": ObjectId("61741c9cbc9ec583c836174c"),
    "subject": "Books on kinematics and dynamics",
    "message": "Hello! Could you recommend good introductory books covering the topics of kinematics and dynamics? Thanks!",
    "posted_on": ISODate("2021-07-23T16:03:21Z")
}

你可以使用之前讨论的两种方法之一——嵌入和子引用——来建模这种关系。如果你选择嵌入，学生的文档可能具有如下结构：

{
    "_id": ObjectId("612d1e835ebee16872a109a4"),
    "first_name": "Sammy",
    "last_name": "Shark",
    "emails": [
        {
            "email": "sammy@example.com",
            "type": "work"
        },
        {
            "email": "sammy@example.com",
            "type": "home"
        }
    ],
    "courses": [
        ObjectId("61741c9cbc9ec583c836170a"),
        ObjectId("61741c9cbc9ec583c836170b")
    ],
    "message_board_messages": [
        {
            "subject": "Books on kinematics and dynamics",
            "message": "Hello! Could you recommend good introductory books covering the topics of kinematics and dynamics? Thanks!",
            "posted_on": ISODate("2021-07-23T16:03:21Z")
        },
        . . .
    ]
}

然而，如果一个学生大量发布消息，他们的文档将很快变得非常长，并可能轻松超过 16MB 大小限制，因此这种关系的基数表明不宜使用嵌入。此外，消息可能需要独立于学生访问，例如留言板页面设计为显示学生发布的最新消息。这种情况也表明嵌入不是此场景的最佳选择。

现在考虑使用子引用而不是嵌入完整文档，如前一个示例所示。单个消息将存储在单独的 collection 中，学生的文档则可以具有以下结构：

{
    "_id": ObjectId("612d1e835ebee16872a109a4"),
    "first_name": "Sammy",
    "last_name": "Shark",
    "emails": [
        {
            "email": "sammy@example.com",
            "type": "work"
        },
        {
            "email": "sammy@example.com",
            "type": "home"
        }
    ],
    "courses": [
        ObjectId("61741c9cbc9ec583c836170a"),
        ObjectId("61741c9cbc9ec583c836170b")
    ],
    "message_board_messages": [
        ObjectId("61741c9cbc9ec583c836174c"),
        . . .
    ]
}

在这个示例中，message_board_messages 字段现在存储 Sammy 撰写的所有消息的子引用。然而，改变方法只解决了之前提到的问题之一，即现在可以独立访问消息。但尽管使用子引用方法学生的文档大小增长会更慢，但鉴于这种关系的无界基数，object identifier 的 collection 也可能变得难以管理。毕竟，一个学生在四年的学习期间可能轻松写下数千条消息。

在这种场景中，将一个对象连接到另一个对象的常见方法是通过父引用。与之前描述的子引用不同，现在不是学生文档引用单个消息，而是消息文档中的引用指向撰写它的学生。

要使用父引用，你需要修改消息文档 schema 以包含对消息作者学生的引用：

{
    "_id": ObjectId("61741c9cbc9ec583c836174c"),
    "subject": "Books on kinematics and dynamics",
    "message": "Hello! Could you recommend a good introductory books covering the topics of kinematics and dynamics? Thanks!",
    "posted_on": ISODate("2021-07-23T16:03:21Z"),
    "posted_by": ObjectId("612d1e835ebee16872a109a4")
}

注意新的 posted_by 字段包含学生文档的 object identifier。现在，学生的文档不会包含他们已发布消息的任何信息：

{
    "_id": ObjectId("612d1e835ebee16872a109a4"),
    "first_name": "Sammy",
    "last_name": "Shark",
    "emails": [
        {
            "email": "sammy@example.com",
            "type": "work"
        },
        {
            "email": "sammy@example.com",
            "type": "home"
        }
    ],
    "courses": [
        ObjectId("61741c9cbc9ec583c836170a"),
        ObjectId("61741c9cbc9ec583c836170b")
    ]
}

要检索学生撰写的消息列表，你将对消息 collection 执行查询，并针对 posted_by 字段进行过滤。将它们放在单独的 collection 中，可以安全地让消息列表增长，而不会影响任何学生文档。

如果你建模一到多关系，其中相关文档的数量是无界的，无论文档是否需要独立访问，通常建议将相关文档单独存储，并使用父引用将它们连接到父文档。

由于 document-oriented databases 的灵活性，在 document databases 中确定最佳的关系建模方式不像在 relational database 中那样是一门严格的科学。通过阅读本文，您已经熟悉了 embedding documents 和使用 child 和 parent references 来存储相关数据。您学到了考虑 relationship cardinality、避免 unbounded arrays，以及考虑 document 是否会单独或频繁访问。

这些只是帮助您在 MongoDB 中建模典型关系的几条指导原则，但数据库 schema 建模并非一刀切。在设计 schema 时，始终要考虑您的 application 以及它如何使用和更新数据。

要了解更多关于 schema design 和在 MongoDB 中存储不同类型数据常见 patterns 的信息，我们鼓励您查看官方 MongoDB 文档的相关主题。