2

私は最近RavenDBを調べ始めましたが、それが私たちのプロジェクトのいくつかに適しているかどうかを確認しようとしました。しかし、単純なデータ構造をモデル化する「正しい」方法に関していくつかの質問に遭遇しました。私はそれを説明しようとします:

  • オブジェクトには、ガイドカテゴリリンクの3種類があります。
  • 「ルート」ガイドには、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にも適合しませんか?

編集(基本的なクエリを追加)

データへのアクセスはかなり簡単です。次の要件があります。

  1. すべてのサブガイドを含むルートガイドのリストを選択します。
  2. 特定のガイド(ルートまたはサブ)については、すべてのサブガイド(ルートの場合)、カテゴリ、およびリンクを取得してください。

基本的に必要なのはそれだけです。ただし、RavenDBなどを評価する理由の1つは、いくつかの検索機能を追加することでした。すでに述べたように、説明、タグなど、リンク、カテゴリ、ガイドに関する情報がいくつかあるので、これらすべてを検索できると便利です。

4

1 に答える 1

2

ガイドがドキュメントになるように処理します。カテゴリとリンクはそのドキュメント内に埋め込まれています。

ガイドには、サブガイドのコレクションを含めることができます。

最初のクエリは、すべてのガイドとそのサブをクエリすることです。あなたはこのようにそれをします:

session.Query<Guide>().Include(x=>x.SubGuides).Where(x=>x.Parent == null).ToList();

これにより、すべてを1つのサーバークエリで実行できます。

session.Include<Guide>(x=>x.SubGuides).Load("guides/123")

これにより、すべてのサブガイドを含むガイドが提供されます。

于 2012-09-11T12:10:54.997 に答える