5

ドキュメント データベース (RavenDB) に格納するエンティティのドキュメント モデルを作成しています。私がモデリングしているドメインは、 を中心に展開していIncidentsます。インシデントには、ソース、優先度、カテゴリ、影響のレベル、およびその他の多くの分類属性があります。RDBMS では、プライオリティ テーブル、カテゴリ テーブル、インパクト テーブルなどへの外部キーを持つインシデント テーブルがありますが、ドキュメント データベースでそれを処理する方法がわかりません (これが私の最初のドキュメント BD です)。

2 種類の参照データがあります。

  1. 単純な参照値: Countries、States、Sources、Languages。属性: 名前しかありませんが、これは多言語システムであるため、各言語に名前があります。サポートされている操作: 作成、削除、名前変更、非アクティブ化、マージ。

  2. 複雑な参照データ: シンプル ルックアップと同じプラス: それらのいくつかには多くのフィールドがあり、独自のビジネス ルールと検証ルールがあります。たとえば、2 つPrioritiesが同じRank値を持つことはできません。Categoriesで構成されているなど、より複雑な構造を持つものもありますSubcategories。

それらをドキュメントとして (またはドキュメントの一部として) どのようにモデル化すればよいでしょうか?

PS:ドキュメント データベース モデリング ガイドラインへのリンクも歓迎します。

4

1 に答える 1

3

関係の処理は、ドキュメントデータベースとSQLデータベースでは大きく異なります。RavenDBのドキュメントでは、これについてここで説明しています。めったに変更されないものについては、非正規化された参照を使用する必要があります。

さらに、RavenDBの主な作成者によるモデリング参照データについての良い議論がここにあります。この例を拡張して、ロケールごとの略語/名前の辞書を非常に簡単に含めることができます。この例は、ここにあります。

特定の質問に答えるには：

  1. 国/州などごとにキーを保存し、このキーを使用して、参照データドキュメント全体をロードし、メモリ内ルックアップを実行することで、ロケール固有のバージョンを取得できます。
  2. 非正規化された参照は、カテゴリに適しています。表示する必要がある場合は、名前や親カテゴリを含めることができます。エンティティ自体が小さいように思われるので、すべてを保存することもできます（非正規化する必要はありません）。複製しても問題ありません。この方法で処理する方が安価で、変更されないか、少なくとも頻繁には変更されません（変更される場合は、パッチを使用して更新できます）。同じことが他のエンティティにも当てはまります。私が見る限り、ビジネスルールはデータベースとは何の関係もありませんが、適切なクエリを実行してそれらを適用できる必要があります。

更新：これは、Ravenでツリー構造を処理する方法を説明する投稿です。

于 2012-11-20T22:15:04.433 に答える