埋め込み（embedding）と参照（referencing）の違いは何ですか？

Question

Accepted Answer

**埋め込み**は関連データをドキュメント内に*ネストして*格納し、**参照**はそれを*別個の*ドキュメントに格納してIDでリンクします。これはMongoDBの中核的なモデリング決定であり、読み取りパフォーマンス、データサイズ、更新の複雑性における異なるトレードオフがあります。

## ドキュメント内にネストした埋め込み

```js
{
  _id: ObjectId("..."),
  title: "My Post",
  author: { name: "Ann", email: "ann@x.com" },   // EMBEDDED author
  comments: [                                      // EMBEDDED comments
    { user: "Bob", text: "Great!" },
    { user: "Carol", text: "Thanks" }
  ]
}
// ✓ ONE query gets the post + author + comments (fast, atomic)
// ✗ if author info changes, must update it in every post embedding it (duplication)
// ✗ document grows with comments → could hit the 16MB limit if unbounded
```

## IDでリンクされた別個のドキュメント：参照

```js
// posts collection
{ _id: ObjectId("p1"), title: "My Post", authorId: ObjectId("u1") }
// users collection
{ _id: ObjectId("u1"), name: "Ann", email: "ann@x.com" }
// comments collection
{ _id: ObjectId("c1"), postId: ObjectId("p1"), user: "Bob", text: "Great!" }

// ✓ author/comments stored ONCE, updated in one place; no document-size issues
// ✓ each entity managed independently
// ✗ need multiple queries or $lookup to combine (slower reads for related data)
```

## トレードオフを並べて比較

```text
                  Embedding                    Referencing
Reads             ✓ fast (one query)           ✗ multiple queries / $lookup
Data duplication  ✗ duplicated (update many)   ✓ stored once
Document size     ✗ grows (16MB limit risk)    ✓ no size concern
Updates           ✗ update in every copy       ✓ update in one place
Atomicity         ✓ atomic (single document)   ✗ across documents
Best for          contains, accessed-together  shared, large, independent, many
```

## ハイブリッドアプローチ（一般的）

```js
// embed a SUBSET for fast reads, reference for the full data
{ title: "Post", author: { _id: ObjectId("u1"), name: "Ann" } }  // enough for display
// → reference (author._id) for full details when needed; embed name for the common read
```

## なぜ重要なのか

埋め込みと参照の違いを理解することは、**MongoDBデータモデリングの中核スキル**であり、効果的なMongoDBアプリケーション設計に必須の知識です。

この決定——関連データをドキュメント内に格納する（埋め込み）か別個のリンクされたドキュメントに格納するか（参照）——は、アプリケーションの読み取りパフォーマンス、データ一貫性、ドキュメントサイズ、更新の複雑性を直接決定し、最も影響力のあるMongoDBの設計上の選択肢となります。

**トレードオフ**を理解することが鍵となります：**埋め込み**は関連データの高速な単一クエリ読み取りとアトミックな更新を提供し（「含む」関係、一緒にアクセスされるデータ、境界のあるサブデータに適する）が、重複（データが共有されている場合の更新の複雑性）とドキュメントの増加（境界のない場合16MBの制限のリスク）を引き起こします。一方、**参照**はデータを1回だけ格納する（簡単な更新、重複なし、サイズの問題なし、独立した管理）が、関連データを結合するために複数のクエリまたは`$lookup`が必要となり（関連データの読み取りが遅い）ます。

どのシナリオにどちらが適合するかを知る——限定的で、所有されている、一緒にアクセスされるデータは埋め込み、大規模で共有されている、独立している、または多くの関係があるデータは参照——は本質的なモデリングの判断です。

一般的な**ハイブリッドアプローチ**（高速読み取りのためにサブセットを埋め込みながら、完全なデータのために参照する——両者の長所を得る）を理解することは、洗練された設計を反映しています。

この決定はMongoDBアプリケーション品質に大きな影響を与え（誤った選択は遅いクエリ、肥大化したドキュメント、または苦しい更新を引き起こす）、SQLに直接的な等価物がない基本的で特徴的なMongoDBモデリングスキル（SQLはデフォルトで正規化される）であるため、埋め込みと参照を理解する——トレードオフ、各々をいつ使うか、ハイブリッドアプローチ——は本質的で高い価値のある知識であり、効果的なMongoDBデータモデリングの中心にあり、アプリケーションのアクセスパターンに対してうまく機能するスキーマを設計する際に最も重要で頻繁に議論されるMongoDBトピックの1つです。