コメント付きの質問構造を設計したいです。コメントには と のどちらの関係を使用すればよいembedですかreference?
質問とコメント、例えばスタックオーバーフローは、次のような構造になります。
Question
title = 'aaa'
content = 'bbb'
comments = ???
embed最初は、次のように埋め込みコメントを使用することを考えました (MongoDB では推奨されていると思います)。
Question
title = 'aaa'
content = 'bbb'
comments = [ { content = 'xxx', createdAt = 'yyy'},
{ content = 'xxx', createdAt = 'yyy'},
{ content = 'xxx', createdAt = 'yyy'} ]
明らかですが、この場合について心配しています。特定のコメントを編集したい場合、その内容と質問をどのように取得するのでしょうか。_idコメントを見つける方法も、質問を見つける方法もありません。(とquestion_refなしでこれを行う方法はあるのでしょうか?)_idquestion_ref
refではなくを使用する必要がありますかembed? その場合、コメント用に新しいコレクションを作成する必要がありますか?
ベストアンサー1
これは科学というより芸術です。スキーマに関する Mongo ドキュメントは良い参考資料ですが、考慮すべき点がいくつかあります。
できるだけ多く入れてください
ドキュメント データベースの利点は、多数の結合が不要になることです。まず、できるだけ多くの情報を 1 つのドキュメントにまとめることをお勧めします。MongoDB ドキュメントには構造があり、その構造内で効率的にクエリを実行できるため (つまり、ドキュメントの必要な部分を取得できるため、ドキュメントのサイズをあまり気にする必要はありません)、SQL のようにデータをすぐに正規化する必要はありません。特に、親ドキュメント以外では役に立たないデータは、同じドキュメントの一部にする必要があります。
複数の場所から参照できるデータを独自のコレクションに分離します。
これは「ストレージ スペース」の問題というよりは、「データの一貫性」の問題です。多数のレコードが同じデータを参照する場合は、1 つのレコードを更新し、そのレコードへの参照を他の場所に保持する方が効率的で、エラーも少なくなります。
ドキュメントサイズの考慮事項
MongoDB は、1 つのドキュメントに 4MB (1.8 では 16MB) のサイズ制限を課しています。GB 単位のデータの世界では、これは小さいように思えますが、3 万件のツイート、250 件の一般的な Stack Overflow の回答、または 20 枚のフリッカー写真にも相当します。一方、これは一般的な Web ページに一度に表示したい情報よりもはるかに多いです。まず、クエリを簡単にする方法を検討してください。多くの場合、ドキュメント サイズに関する懸念は、時期尚早な最適化になります。
複雑なデータ構造:
MongoDB は任意の深いネスト構造のデータを保存できますが、効率的に検索することはできません。データがツリー、フォレスト、またはグラフを形成する場合、各ノードとそのエッジを別々のドキュメントに保存する必要があります。(このタイプのデータ用に特別に設計されたデータ ストアも検討する必要があることに注意してください)
また、指摘されたドキュメント内の要素のサブセットを返すことは不可能です。各ドキュメントからいくつかの部分を取り出す必要がある場合は、それらを分離する方が簡単です。
データの一貫性
MongoDBは効率性と一貫性をトレードオフしています。ルールは、単一のドキュメントへの変更は常に 原子ただし、複数のドキュメントの更新はアトミックであると想定しないでください。また、サーバー上のレコードを「ロック」する方法はありません (たとえば、「ロック」フィールドを使用して、クライアントのロジックにこれを組み込むことができます)。スキーマを設計するときは、データの一貫性を維持する方法を検討してください。一般に、ドキュメントに保存するデータが多いほど、優れています。
あなたが説明していることについては、コメントを埋め込み、各コメントに ObjectID を持つ ID フィールドを指定します。ObjectID にはタイムスタンプが埋め込まれているため、必要に応じて created at の代わりにそれを使用できます。