私は自分のシステムにこれを最適に実装する方法を見つけようとしています...そして今のところRDBMSスペースから頭を出してください...
現在のDBの一部には、Show、ShowEntry、およびEntryの3つのテーブルがあります。基本的に、ShowEntryは、ShowとEntryの間の多対多の結合テーブルです。私のRDBMSでは、詳細を表示するための変更は1か所で行うことができ、エントリでも同じであるため、これは非常に論理的だと考えています。
これをドキュメントベースのストレージに反映するための最良の方法は何ですか？これを行う方法は1つではないと確信していますが、この場合、ドキュメントベースのストレージが適切かどうかを考えずにはいられません。
参考までに、私は現在RavenDBの実装を検討しています。一般的なNoSQLの設計に関する議論は良いものですが、RavenDBに焦点を当てたものは素晴らしいものになります。
ありがとう。
ドキュメントデータベースで多対多の関係をモデル化する場合、通常、外部キーのコレクションをドキュメントの1つだけに格納します。選択するドキュメントは、関係をトラバースする方向によって大きく異なります。一方向にトラバースするのは簡単ですが、他の方法でトラバースするにはインデックスが必要です。
買い物かごの例を見てみましょう。どのバスケットに特定のアイテムが入っているかよりも、どのアイテムが特定のバスケットに入っているかを正確に知ることが重要です。通常、バスケットからアイテムへの方向の関係に従うため、バスケットIDをアイテムに格納するよりも、アイテムIDをバスケットに格納する方が理にかなっています。
インデックスを使用して、関係を反対方向にトラバースすることもできます（たとえば、特定のアイテムを含むバスケットを見つける）が、インデックスはバックグラウンドで更新されるため、常に100％正確であるとは限りません。（でインデックスが正確になるのを待つことができますがWaitForNonStaleResults、その遅延はUIに表示されます。）
両方向ですぐに100％の精度が必要な場合は、両方のドキュメントに外部キーを保存できますが、関係が作成または破棄されるたびに、アプリケーションは2つのドキュメントを更新する必要があります。
これは私の質問を解決するのに大いに役立ちました！
質問への回答
NoSQLの多対多の関係は、エンティティの1つで参照の配列を介して実装されます。2つのオプションがあります。
ShowEntryアイテムの配列があります。Entryの配列がありShowます。配列の場所は、クエリの最も一般的な方向によって決定されます。レコードを他の方向に解決するには、配列にインデックスを付けます（RavenDBではチャームのように機能します）。
通常、両方のエンティティに2つの配列が互いに向き合っていると、喜びよりも悲しみが増します。結果整合性のある環境では、信頼できる唯一の情報源を失っています...データの整合性を損なう可能性があります。
この記事をチェックしてください-NoSQLのエンティティ関係（1対多、多対多）。パフォーマンス、運用コスト、開発と保守の時間/コストを考慮に入れて、さまざまな角度からエンティティの関係をカバーし、RavenDBの例を提供します。