你如何在 MongoDB 中设计 schema？

Question

Accepted Answer

MongoDB 的 schema 设计核心在于一个关键决策：**内嵌（embedding）**（将相关数据存储在同一个文档内）与**引用（referencing）**（将相关数据存储在独立的文档/集合中并通过引用关联）之间的选择。与 SQL 默认规范化（normalize）的做法不同，MongoDB 的设计是围绕数据如何被*访问*来优化的。

## 内嵌（Embedding）——将相关数据存储在一起

```js
// embed related data within the document
{
  _id: ObjectId("..."),
  name: "Ann",
  address: { city: "NY", zip: "10001" },        // embedded sub-document
  orders: [                                      // embedded array of orders
    { product: "Phone", amount: 999 },
    { product: "Case", amount: 20 }
  ]
}
// → ONE query gets the user AND their address AND orders (no joins)
```

**内嵌**将相关数据保存在一个文档中——一次查询即可读取全部数据（速度快，无需 join）。适用于经常一起访问的数据以及“包含（contains）”关系。

## 引用（Referencing）——关联独立的文档

```js
// store a reference (id) to a document in another collection
{ _id: ObjectId("u1"), name: "Ann" }                          // users collection
{ _id: ObjectId("o1"), userId: ObjectId("u1"), product: "Phone" } // orders collection
// → query orders by userId; use $lookup to join when needed
```

**引用**将数据分开存储，并通过 id 进行关联（类似外键）——可以分别查询，或在需要时用 `$lookup` 进行 join。

## 何时内嵌、何时引用

```text
EMBED when:
  ✓ data is accessed TOGETHER (read the parent → you want the children)
  ✓ a "contains"/ownership relationship (address, order line items)
  ✓ the embedded data is bounded (not unboundedly growing)
  ✓ one-to-few relationships

REFERENCE when:
  ✓ data is large or grows UNBOUNDEDLY (avoid huge documents — 16MB doc limit!)
  ✓ data is accessed/updated INDEPENDENTLY
  ✓ many-to-many or one-to-many with many
  ✓ the same data is shared/referenced by many documents (avoid duplication)
```

## 围绕访问模式来设计（关键原则）

```text
MongoDB schema design is driven by HOW YOU QUERY the data, not pure normalization:
  → Structure data so common queries are efficient (often a single document read).
  → "Data that is accessed together should be stored together."
  → This may mean DENORMALIZING (some duplication) for read efficiency — acceptable
    in MongoDB, traded against update complexity.
```

## 为什么这很重要

schema 设计在 MongoDB 中至关重要——它与 SQL 中的做法不同，甚至可以说影响更为深远，因为 MongoDB 灵活的文档模型给了你诸多选择，这些选择会显著影响性能和可维护性，因此理解它对于构建高效的 MongoDB 应用至关重要。

核心决策——**内嵌 vs 引用**——是 MongoDB 最具决定性的设计选择：**内嵌**（将相关数据存储在一个文档内）能够实现对相关数据的快速单次查询读取（无需 join），适用于一起访问的数据和“包含”关系；而**引用**（通过 id 关联独立的文档）则适用于大型/无上限增长的数据、需要独立访问的数据以及共享/多对多关系。

理解**何时使用每一种方式**（对有边界、一起访问、被拥有的数据使用内嵌；对大型/持续增长、独立、共享或多对多关系的数据使用引用——并时刻注意 MongoDB 的 16MB 文档大小限制）是关键技能。

最重要的是，理解其指导原则——**围绕访问模式来设计**（围绕*你如何查询数据*来组织数据结构，从而使常见查询高效，通常只需一次文档读取，而不是像 SQL 那样默认进行规范化）——才是区分优秀 MongoDB schema 设计的关键所在。

这可能意味着为了读取效率而接受一定程度的**反规范化（denormalization）**（数据冗余），这是相对于更新复杂度的一种权衡，在 MongoDB 中是可以接受的，而且往往是正确的选择。

由于 schema 设计深刻影响 MongoDB 应用的性能和可维护性（糟糕的内嵌/引用选择会导致查询缓慢、文档过大或更新复杂），并且这种由访问模式驱动、在内嵌与引用之间取舍的方法与 SQL 的规范化有着本质区别，因此理解 MongoDB 的 schema 设计——内嵌/引用决策、何时使用每一种、以及围绕访问模式来设计——是构建高效 MongoDB 应用所必备的高价值知识，也是最重要、最具特色的 MongoDB 主题之一，正是它将那些能够设计出优秀文档 schema 的人与那些只会生搬硬套关系型设计的人区分开来。