私は最近RavenDBを調べ始めましたが、それが私たちのプロジェクトのいくつかに適しているかどうかを確認しようとしました。しかし、単純なデータ構造をモデル化する「正しい」方法に関していくつかの質問に遭遇しました。私はそれを説明しようとします:
- オブジェクトには、ガイド、カテゴリ、リンクの3種類があります。
- 「ルート」ガイドには、0個以上のサブガイドを含めることができます
- ガイドには0個以上のカテゴリを含めることができます
- カテゴリには0個以上のリンクを含めることができます
視覚的に構造は次のようになります。
- ルートガイド(0以上)
- サブガイド(0以上)
- カテゴリ(0以上)
- リンク(0以上)
- カテゴリ(0以上)
- カテゴリ(0以上)
- リンク(0以上)
- サブガイド(0以上)
実際のデータでは、各ルートガイドの下に約20のルートガイドと約3〜5のサブガイドがあります。各ガイド(ルートガイドとサブガイドの両方)の下には、15〜25のカテゴリがあります。また、各カテゴリの下には5〜20のリンクがあります。
私の最初の考えは、次のようにモデル化することでした(簡略化されたモデル):
Guide
---------------
Id
ParentGuideId
Title
Category
---------------
Id
GuideId
Title
Link
---------------
Id
CategoryId
Title
これはほとんどリレーショナルモデルであり、これはRavenDBでデータをモデル化する正しい方法ではない可能性があることを認識しています。では、代替手段は何ですか?問題は、私が次のように階層を保存したくないということだと思います。
Guide
---------------
Id
Title
SubGuides
Categories
SubGuide
---------------
Title
Categories
Category
---------------
Title
Links
Link
---------------
Title
何千ものサブオブジェクトが含まれる可能性のあるドキュメントが作成されるためです。上記のモデルは簡略化されていることに注意してください。実際には、各タイプにははるかに多くのデータがあるため、このモデルを使用した場合、RavenDBの20のルートガイドドキュメントは膨大になります。
代替案はありますか?多分それは私の長年の悪いリレーショナルデータベースの育成の話ですが、多分このシナリオは単にRavenDBに適合せず、SQLにも適合しませんか?
編集(基本的なクエリを追加)
データへのアクセスはかなり簡単です。次の要件があります。
- すべてのサブガイドを含むルートガイドのリストを選択します。
- 特定のガイド(ルートまたはサブ)については、すべてのサブガイド(ルートの場合)、カテゴリ、およびリンクを取得してください。
基本的に必要なのはそれだけです。ただし、RavenDBなどを評価する理由の1つは、いくつかの検索機能を追加することでした。すでに述べたように、説明、タグなど、リンク、カテゴリ、ガイドに関する情報がいくつかあるので、これらすべてを検索できると便利です。