2

私は、ドキュメント データベースに足を踏み入れる方法として、簡単なフォーラムをまとめています。モデル化するのは比較的簡単なことだと考えています。

ドキュメントをどのように保管すればよいかを正確に把握するのに苦労しています。現時点では RavenDB を使用していますが、他のドキュメントでも同様になると思います。データベース。

つまり、基本的に、Forums各フォーラムには多数の がThreadsあり、各スレッドにはPostsによって作成された多数のスレッドが含まれていUsersます。

私の頭の中で、これらのそれぞれが別個のドキュメントであるようにプロットしました。これは主に、それぞれForumが何千もの を持つ可能性がThreadsあり、それぞれThreadが何千ものPosts. 明確でないドキュメントを持っていると、時間の経過とともにそれらが巨大になるように思われますか?

すべてのリストを表示するページを表示するときに、名前 (大したことはありません) と投稿数Postsを表示したいと思います。ここが私が立ち往生している場所です。AuthorAuthor

変更される可能性は低いため、Author名前を投稿Authorに保存できますが、投稿数は常に変化するため、Post.

したがって、50 件の投稿があるページを表示している場合、現在のAuthor投稿数を取得するには、結合に相当するリレーショナル処理を実行する必要があります。これは、ドキュメント DB がこのシナリオに適していない場合を除き、私が間違っていることを示していますか?

編集

RavenDBのLive Projectionsはこれを問題なく処理できるように見えますが、考えられる代替 DB 設計についてコメントを残しておきたいと思います。

4

1 に答える 1

1

私は本当に似たような状況について考えていました。そして、私はあなたと同じ結論に達しました。しかし、私は何かを忘れていました。あなたも同じことを忘れているかもしれません: ドキュメント DB は非常に非正規化された性質を持っています。そのため、ravenDB でライブ プロジェクションを使用できますが、通常はデータを複製するため、特別な場合に限ります。例えば：

役職：

  • ThreadId (フィルタリングに必要)

  • 文章

  • AuthorId

  • 作成者ユーザー名

  • 作成者最終ログイン

  • 作者Anything

このようにして、後で必要になった場合に作成者の ID を取得できますが、最も使用されているデータを非正規化して、結合やライブ プロジェクションなしで利用できます。

著者の投稿数の場合、map/reduce インデックスを使用する必要があります。これらのインデックスは継続的に再生成されています。そのため、著者が投稿を行ったとき、カウントはすぐには更新されませんが、最終的には一貫性が保たれます。これはドキュメント DB の重要な部分です。

これが役立つことを願っています

于 2011-01-12T23:44:31.057 に答える