1対多の関係クエリでカウントするためのベストモデリング

Question

モデリングソリューションの選択には助けが必要です。

私はテーブルBの多くの他のものに関連するレコードを持つテーブルAを持っています：例えば、テキスト（A）とそれを好んだユーザー（B）または製品（A）xレビュー（B）

だから、どれくらいの人がテキストをお気に入りにしたり、商品をレビューしたかを知りたい。これは、この状況のた​​めの唯一のクエリですが、テーブルが増えるにつれて複雑になることがあります。たとえば、クチコミ+商品に含まれているクチコミ+写真のレビューやレビューが全くないユーザー名を見つけたり、レビューに関連しているが調整のためにブロックされたりしているユーザー名を検索するなどです。表Aは、ちょうどテーブルBに関連しているレコード数をカウントするための列を持っている場合

はまだ、それは私が知っている、そのためにクエリを実行することは可能ですが、...

はそれがより良いソリューションですか？ Favorite_Count、review_count、review_avgのように...

これは、誰かが好きな、または好きなものを選んでいないときに、ちょっとしたコーディングと引き換えに、複雑なクエリで「結合を保存する」でしょう。結局のところ、クエリは読みやすく、おそらく速いでしょう。

あなたはどう思いますか？

Answer 1

データ検索が高速になります。データの挿入と更新が遅くなります。それはトレードオフです。比率は読み込みと書き込みに依存します。

StackOverflowがどのようにこれを行うかを調べることは、貴重なことです。データベーススキーマhereを調べることができます。

は、例えば、それらは容易Posts（階層構造）とPostTagsに参加それぞれ追加してたびに取得することができるにもかかわらず、Postsテーブル内AnswerCountとTagsを置きます。

私の意見では、この情報は更新された情報よりも頻繁に読み込まれるからです。投稿リストを通過するユーザーの数と、実際に投稿ごとに何人がクリックしたかを想像してください。メインページに投稿リストを作成するには、誰かがそれを更新するたびにこれらの結合を実行するための時間が必要です。それは注目すべきトラフィックでしょうか？

しかし、それはすべてあなたのケースのシナリオによって異なります。この場合、「最良のアプローチ」はありません。

Answer 2

私はこの問題のインデックス付きのビューで良い経験をしました。これらはカウント計算に非常に適しています。 「通常の」ビューとは対照的に、レコードはSql-Serverのインデックスとして格納され、関連するテーブルが変更されると自動的に更新されます。しかし、これらにはいくつかの制限があります。スキーマバインディングは必須ですが、内部結合のみを使用できます。私は複数のインデックス付きビューを作成してからクエリを実行します。詳細については、MSDN Create Indexed Viewsを参照してください。

CREATE VIEW dbo.v_productReviewsCount 
    WITH SCHEMABINDING 
AS 
    SELECT T1.productId, 
     COUNT_BIG(*) AS [count] 
    FROM [dbo].[products] T1 
     INNER JOIN [dbo].[reviews] T2 
       ON T1.productId = T2.productId 
    GROUP BY T1.productId 

GO 

CREATE UNIQUE CLUSTERED INDEX ix_productReviewsCount_productId ON dbo.v_productReviewsCount (productId) 

GO