質問

私はこれを自分のシステムに最適に実装する方法を見つけようとしています...そして今のところはRDBMSスペースから頭を離れてください...

現在の DB の一部には 3 つのテーブルがあります。表示、表示エントリ、およびエントリ。基本的に、ShowEntry は Show と Entry の間の多対多の結合テーブルです。私の RDBMS の考え方では、Show 詳細への変更は 1 か所で行うことができ、Entry についても同様であるため、これは非常に論理的です。

これをドキュメントベースのストレージに反映する最善の方法は何でしょうか?これを行う唯一の方法はないと思いますが、そもそもドキュメントベースのストレージがこのケースに適切であるかどうかを考えずにはいられません。

参考までに、私は現在 RavenDB の導入を検討しています。一般的な NoSQL 設計に関する議論は良いものですが、より RavenDB に焦点を当てた議論は素晴らしいものになるでしょう。

感謝 D.

役に立ちましたか?

解決

ドキュメント データベースで多対多のリレーションシップをモデル化する場合、通常は、外部キーのコレクションをドキュメントの 1 つのみに保存します。どの文書を選択するかは、関係をどの方向に進めるかによって大きく異なります。一方向に走査するのは簡単ですが、逆方向に走査するにはインデックスが必要です。

買い物かごの例を見てみましょう。どのバスケットに特定の商品が入っているかよりも、特定のバスケットにどの商品が入っているかを正確に知ることの方が重要です。通常は、バスケットから商品の方向の関係を追跡するため、商品にバスケット ID を保存するよりも、商品 ID をバスケットに保存する方が合理的です。

関係を逆方向にたどることもできます (例:インデックスを使用して特定の商品を含むバスケットを検索しますが、インデックスはバックグラウンドで更新されるため、常に 100% 正確であるとは限りません。(インデックスが正確になるまで待つことができます。 WaitForNonStaleResults, ただし、その遅延は UI に表示されます。)

両方向で即座に 100% の精度が必要な場合は、両方のドキュメントに外部キーを保存できますが、アプリケーションはリレーションシップが作成または破棄されるたびに 2 つのドキュメントを更新する必要があります。

他のヒント

これ 私の質問を解決するために大いに役立ちました!

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top