2016-11-18 70 views
0

我需要幫助來選擇建模解決方案。用於計算一對多關係查詢的最佳建模

我有一個表A,其中涉及到表B中的許多其他人。例如:文本(A)和收藏它的用戶(B)或產品(A)x評論(B)。

所以...我想知道有多少人收藏了文本或查看了產品。好吧,這很簡單,只是這種情況只有一個查詢,但當我開始加入更多表時,可能會變得複雜。例如,要查找包含在評論+產品中的評論+照片的評論+照片的平均值,而沒有評論,以及評論相關的時候,但仍然因適度而受阻的用戶名等。

不過,這是可以做到的,一個查詢,我知道,但是...

它是一個更好的解決方案。如果表A有一欄只是爲了計算有多少條記錄在表B中有關係嗎? Like Favorite_Count,review_count,review_avg,...

這會在複雜的查詢中「保存連接」,以換取只有一點點編碼,當有人喜歡或不喜歡的東西。最後,查詢會更容易閱讀,並且可能更快,對嗎?

您認爲如何?

+1

我害怕以這種方式在表格中存儲彙總數據。如果你的應用程序行爲不端,會有人不得不說,嘿這些數字不匹配,那麼你需要一個過程來確保它們匹配,接下來你將管理聚集器運行多久以糾正不良應用程序寫入,與此同時,其他應用程序正在網上購買,這些應用程序會爲您的聚合帶來自己的問題。 GROUP BY和INNER JOINS是你的朋友。也許你可以看看一個只讀數據庫,報告可能會跑掉並在那裏展平你的數據。 –

+0

我看到卡米爾的觀點,並在極重讀取的情況我能理解的管理更新的信息到您的基表的複雜性被認爲的,但我會和羅斯,通常是不需要的併發症,只是爲失敗的另一點側。另外,如果你想同時得到詳細數據和聚合技術,如分區窗口功能,並將它與正確的索引和優化APPLY能保持讀取,即使在高需求的情況下快速 – Matt

+0

是的,我同意了一下你。但是由於系統不會從外部輸入輸入,所以從API或其他系統不會有更新錯誤。但無論如何這是一個好點。 不過,要在現實中的例子來看看。這就是我想要做的,它是很難:http://stackoverflow.com/questions/40346096/designing-and-querying-product-review-system 我要考慮封鎖和隱藏的審查和產品無評論,除了計算外,還可以對評論進行平均(只有那些未被阻止和隱藏的評論)。 因爲我不是一個SQL專家,它ishard給我。 :( – mEba

回答

0

數據檢索會更快。數據插入和更新會更慢。這是一個折衷。這取決於比率讀取與寫入。

這將是非常有價值的你調查例如如何StackOverflow做到這一點。您可以檢查數據庫模式here

例如,他們把AnswerCountTagsPosts表內,即使他們可以很容易地檢索每次有額外分別加入到Posts(層次結構)和PostTags

在我看來,他們爲此付出了努力,因爲這些信息經常被讀取而不是更新。想象一下有多少用戶通過帖子列表,每個帖子有多少人點擊。要在主頁上創建帖子列表,每次有人刷新時都需要額外的時間來執行這些連接。這將是值得注意的流量,不是嗎?

但是,這一切都取決於你的情況。在這種情況下沒有「最佳方法」。

+0

是的,這裏是相同的情況,額外的代碼將在更新中完成。/unblock/delete a review。但是,rading會針對每一個產品,也會針對一個大型的,有目的的產品列表。收藏夾容易一些...喜歡或不喜歡會觸發該功能。 – mEba

0

我已經對這個問題的索引視圖做了很好的體驗。這些非常適合計數計算。與「正常」視圖相反,記錄作爲索引存儲在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