データをどのように使用するかを反映する方法で、コレクションとドキュメントを構造化する必要があります。特にサブドキュメントを使用して、複雑なクエリを多数実行する場合は、ドキュメントを個別のコレクションに分割する方が簡単な場合があります。この例は、ブログ投稿からコメントを分割することです。
コメントは、サブドキュメントの配列として保存できます。
# Example post document with comment subdocuments
{
title: 'How to Mongo!'
content: 'So I want to talk about MongoDB.',
comments: [
{
author: 'Renold',
content: 'This post, it's amazing.'
},
...
]
}
ただし、コメントだけに対して複雑なクエリを実行したい場合 (たとえば、すべての投稿から最新のコメントを選択したり、1 人の作成者によるすべてのコメントを取得したりする場合)、これは問題を引き起こす可能性があります。これらの複雑なクエリを作成する予定がある場合は、コメント用と投稿用の 2 つのコレクションを作成します。
# Example post document with "ForeignKeys" to comment documents
{
_id: ObjectId("50c21579c5f2c80000000000"),
title: 'How to Mongo!',
content: 'So I want to talk about MongoDB.',
comments: [
ObjectId("50c21579c5f2c80000000001"),
ObjectId("50c21579c5f2c80000000002"),
...
]
}
# Example comment document with a "ForeignKey" to a post document
{
_id: ObjectId("50c21579c5f2c80000000001"),
post_id: ObjectId("50c21579c5f2c80000000000"),
title: 'Renold',
content: 'This post, it's amazing.'
}
これは、リレーショナル データベースに「ForeignKeys」を格納する方法に似ています。このようにドキュメントを正規化すると、コメントと投稿の両方のクエリが簡単になります。また、ドキュメントを分割しているため、各ドキュメントが消費するメモリが少なくなります。ただし、トレードオフは、ObjectId
いずれかのドキュメントに変更があった場合 (たとえば、コメントまたは投稿を挿入/更新/削除するとき) に参照を維持する必要があることです。また、Mongo にはイベント フックがないため、次のことを行う必要があります。アプリケーションでのこのすべてのメンテナンス。
一方、ドキュメントのサブドキュメントに対して複雑なクエリを実行する予定がない場合は、モノリシック オブジェクトを格納することでメリットが得られる可能性があります。たとえば、ユーザーの好みは、クエリを作成する可能性が高いものではありません。
# Example user document with address subdocument
{
ObjectId("50c21579c5f2c800000000421"),
name: 'Howard',
password: 'naughtysecret',
address: {
state: 'FL',
city: 'Gainesville',
zip: 32608
}
}