私は最高の私のシステムのためにこれを実装する...そして今のRDBMSスペースの外に私の頭を取得する方法を把握しようとしています...私の現在のDBの基本のNoSQLは、文書のデザインの質問
部分があり3つのテーブル：Show、ShowEntry、およびEntry。基本的にShowEntryは、ShowとEntryの間の多対多の結合テーブルです。私のRDBMSの考え方では、Showの詳細の変更は1か所で、Entryと同じことができるので、かなり論理的です。
これをドキュメントベースのストレージに反映するには、どのような方法が最適ですか？これを行う方法はないと確信していますが、ドキュメントベースのストレージがこのケースにはまったく適しているかどうかは考えていません。
参考までに、現在RavenDBの実装を検討中です。一般的なNoSQLの設計についての議論は良いものになるでしょうが、RavenDBに焦点を絞った方が素晴らしいでしょう！
おかげで、 D.
ドキュメントデータベースで多対多リレーションシップをモデリングする場合、通常、ドキュメントのうちの1つに外部キーのコレクションを格納します。あなたが選ぶ文書は、関係を横断しようとする方向に大きく依存します。それを一方向に横断することは自明であり、逆にそれを横切ることは、索引を必要とする。
買い物かごの例をご覧ください。どのバスケットが特定のアイテムを含むかよりも、特定のバスケット内にあるアイテムを正確に知ることが重要です。私たちは通常、バスケットからアイテムへの方向性の関係に従っているので、アイテムIDをアイテムに格納するよりも、アイテムIDをバスケットに格納する方が意味があります。
インデックスを使用して逆の方向にリバーストラバース（特定のアイテムを含むバスケットを検索）することはできますが、インデックスはバックグラウンドで更新されるため、必ずしも100％正確ではありません。
双方向で100％の精度が直ちに必要な場合は、両方のドキュメントに外部キーを格納することはできますが、アプリケーションにはアプリケーションを格納することができます関係が作成または破棄されるたびに2つの文書を更新する必要があります。
Thisは私の質問の解決に向けた長い道のりを行ってきました！
ありがとう - 素晴らしい説明。私は両側に外部キーを格納することと、ある種の関係のために片側だけを格納するという組み合わせを行ってきました。各方向の関係にアクセスする私のUIの頻度はかなり重要です。 – codedog
+1良いと構造化の説明のために。 –