1

ケース: システムにユーザーがいて、静的なドキュメント (本など) がある 各ユーザーはいくつかのドキュメントを操作し、ドキュメントごとに特定の状態/設定 (ドキュメント内の現在の位置/ページ、ブックマーク/メモなど) を持っている場合があります。

userId と documentId の 2 つのキー、または userId に等しい _id と documentId に等しい _id を持つサブドキュメントのネストされた配列を持つコレクション (そのシナリオでは、コレクションも使用されます非ドキュメント固有のユーザー データを格納する)?

最初のシナリオ: find({userId: ..., documentId:...})

2 番目のシナリオ: findBy({_id:...})、次に documentId と等しい _id を持つサブドキュメントを検索

最初のシナリオの長所:

1) 検索と保存の操作が速くなると思います。

最初のシナリオの短所:

1) 書類の量が増える

2) ドキュメントに関連しないユーザー固有のデータをコレクションに保存する方法がない

2番目のシナリオの長所:

1）データ関係のより良い表現（主観的ですが）

2) 同じコレクションを使用して、特定のドキュメントに関連しない他のユーザー データを格納することができます。

2番目の短所：

1）検索と保存操作がより困難になり（私はMongoose ODMを使用しており、コードは複雑ではありません）、操作は最初のシナリオよりも速度が遅いと思います。

考慮すべき事項:

1）一般的に、読み取り操作では、ドキュメント固有のデータを1つだけ選択します

2) 1 つのドキュメント固有のデータを頻繁に保存する必要があります (たとえば、ユーザーが作業しているドキュメント内の位置を定期的に保存するなど)。

3）ユーザー/ドキュメントの状態には、変更する必要があるネストされた配列（ブックマーク、メモ）が含まれる場合があります（ドキュメントの挿入/削除）

この点を考慮すると、最初のシナリオの方がタスクに適していると言えますが、2 つのシナリオが大きく異なるかどうか、プロの意見を聞きたいと思います。

4

1 に答える 1

2

実際のアクセス パスは何ですか? ユーザー ID から始めて、ユーザーが読むドキュメントを探しますか? それとも、ドキュメントから始めて、それを読んだユーザーを検索しますか? ドキュメント オブジェクトは軽量 (タイトルと作成者などの情報のみ) ですか、それとも重量 (コンテンツを含む) ですか? ドキュメントが重い場合は、それらを別のコレクションに保管して、シナリオ 2 に進みます。

基本的に、シナリオ 1 はリレーショナル ソリューションを模倣しており、シナリオはオブジェクト モデルのように見えます。

オブジェクト モデルは現実をより適切に記述し、より効率的であると私は信じています。

したがって、読者に本を頻繁に検索しない限り、シナリオ 2 を使用します。

于 2013-02-15T09:53:19.640 に答える