参照の基本概念
MongoDBはドキュメント指向データベースですが、リレーショナルデータベースのような関係性を表現するために、ドキュメント間で参照を持つことができます。主な参照パターンとして「親から子への参照」と「子から親への参照」があります。
1. 親から子への参照（Parent References Children）
親ドキュメントが子ドキュメントのIDを配列として保持するパターンです。
構造例
親ドキュメント（authors）
{
_id: ObjectId("..."),
name: "山田太郎",
books: [
ObjectId("book1"),
ObjectId("book2"),
ObjectId("book3")
]
}
子ドキュメント（books）
{
_id: ObjectId("book1"),
title: "MongoDBの基礎",
year: 2023
}
メリット
- 親から子のリストを直接取得できる
- 親ドキュメントを見るだけで、関連する子の数や存在を把握できる
- 子が少数の場合、管理が簡単
デメリット
- 子の数が増えると親ドキュメントのサイズが肥大化する（16MBの制限に注意）
- 子を追加・削除するたびに親ドキュメントの更新が必要
- 大量の子を持つ場合、パフォーマンスが低下する
適用シーン
- 子の数が限定的（数十〜数百程度）
- 親から子の一覧を頻繁に取得する
- 例：ユーザーと投稿、カテゴリと商品
2. 子から親への参照（Child References Parent）
子ドキュメントが親ドキュメントのIDを保持するパターンです。
構造例
親ドキュメント（authors）
{
_id: ObjectId("author1"),
name: "山田太郎"
}
子ドキュメント（books）
{
_id: ObjectId("..."),
title: "MongoDBの基礎",
year: 2023,
author_id: ObjectId("author1")
}
メリット
- 親ドキュメントのサイズが一定に保たれる
- 子の数が無制限に増やせる
- 子の追加・削除が親に影響しない
- インデックスを作成すれば効率的にクエリできる
デメリット
- 親から子を取得する際に別途クエリが必要
- 集約や結合処理が必要になる場合がある
適用シーン
- 子の数が多い、または無制限に増える可能性がある
- 子から親を参照する頻度が高い
- 例：ブログ記事とコメント、注文と注文明細
使い分けの判断基準
親から子への参照を選択する場合
- 子の数が制限的（通常100以下）
- 親と子を同時に取得することが多い
- 子のリストを頻繁に表示する
子から親への参照を選択する場合
- 子の数が多い、または予測できない
- 子を個別に扱うことが多い
- スケーラビリティが重要
両方向参照
場合によっては、両方向から参照を持つこともあります。これはクエリのパフォーマンスを最適化したい場合に有効ですが、データの一貫性を保つための管理が複雑になります。
// 親
{
_id: ObjectId("author1"),
name: "山田太郎",
books: [ObjectId("book1"), ObjectId("book2")]
}
// 子
{
_id: ObjectId("book1"),
title: "MongoDBの基礎",
author_id: ObjectId("author1")
}
まとめ
参照パターンの選択は、データの性質とアクセスパターンによって決まります。一般的には、子から親への参照の方がスケーラブルで柔軟性が高いため、多くの場合に推奨されます。ただし、具体的な要件に応じて最適なパターンを選択することが重要です。