要聚合還是不聚合，那就是數據庫模式設計問題

如果您正在執行min/max/avg查詢，那麼您更喜歡使用聚合表還是僅查詢原始表中的一系列行？要聚合還是不聚合，那就是數據庫模式設計問題

這顯然是一個非常開放的問題，沒有一個正確的答案，所以我只是尋找人們的一般建議。假設原始數據表由一個時間戳，一個數字外鍵（比如用戶ID）和一個十進制值（比如購買金額）組成。此外，假設表中有數百萬行。

我已經完成並且被撕裂了。一方面，聚合表爲我提供了更快的查詢速度，但代價是增加了額外的表。顯示聚合範圍的當前值要麼完全返回到原始數據表或組合更多細粒度聚合。我發現在應用程序代碼中追蹤哪個聚合表要查詢何時需要更多的工作，並且需要更改模式，因爲原始聚合範圍總是不夠用（「但我想看看我們在過去3個薪酬階段的銷售額！「）。

另一方面，從原始數據查詢可能會受到懲罰，但讓我對數據範圍非常靈活。當範圍邊界發生變化時，我只需更改查詢而不必重新生成聚合表。同樣，應用程序代碼也需要更少的更新。我懷疑如果我的索引更聰明（即總是有很好的覆蓋索引），我可以減少從原始數據中選擇的懲罰，但這決不是萬能藥。

無論如何我能擁有兩全其美？

來源

2009-12-23 pr1001

這是幹什麼用的數據庫？ – 2009-12-23 23:33:55

我通常使用MySQL，但希望人們的提示適用於所有SQL數據庫。 – pr1001 2009-12-23 23:46:15

@ pr1001：這在一定程度上是一個普遍問題，但是一些數據庫提供了使這個問題更容易的機制（例如Oracle的「物化視圖」），所以這樣做「正確」將會是數據庫特定的程度 – skaffman 2009-12-24 10:41:44

我們遇到了同樣的問題，並遇到了相同的問題。我們最終將報告切換到Analysis Services。 MDX和Analysis服務本身有一條學習曲線，但它很棒。我們發現的一些好處是：

對於您有很多靈活性，可以以任何您想要的方式查詢。在我們必須建立特定聚合之前，但現在一個多維數據集回答了我們所有的問題。
存儲在一個立方體中比詳細數據要小得多。
建築及處理花費較少的時間和比聚集體確實產生了數據庫服務器上較少負載的立方體。

一些缺點：

周圍有建築多維數據集和學習MDX一個學習曲線。
我們必須創建一些工具來自動處理立方體。

UPDATE：既然你使用MySQL，你可以看看Pentaho Mondrian，這是支持MySQL的開源OLAP解決方案。我從來沒有使用它，所以我不知道它是否會爲你工作。有興趣知道它是否適合你。

來源

2009-12-23 23:36:21 jvilalta

+ 1提到Pentaho。一些參與Pentaho的人來自BI的Cognos名聲。 – cethegeek 2009-12-24 14:38:06

我總是傾向於原始數據。一旦彙總，你不能回去。
與刪除無關 - 除非有最簡單的聚合數據集，否則無法準確地將數據恢復/轉置回原始數據。

理想情況下，我會使用物化視圖（假設數據可以適應約束），因爲它實際上是一個表。但是MySQL不支持它們，所以下一個考慮因素是計算列的視圖或更新實際表的觸發器。

來源

2009-12-24 00:42:44

我是否錯過他建議聚合和刪除原始數據的部分？當然，原始數據需要保留。但除了原始數據之外，一些彙總數據也可以存儲。 – marcc 2009-12-24 00:46:22

@marcc：我在哪裏說原始數據會被刪除？ – 2009-12-24 01:02:16

@Ponies：也許當你說，一旦彙總，你不能回去:) – 2009-12-24 11:13:53

它有助於選擇一個好的主鍵（即[user_id，used_date，used_time]）。對於一個常量user_id，在used_date上做一個範圍條件非常快。

但隨着表的增長，您可以通過聚合到像[user_id，used_date]這樣的表來縮小表的大小。對於時間不重要的每個範圍，您可以使用該表格。另一種縮小表格大小的方法是歸檔您不再（允許）查詢的舊數據。

來源

2009-12-24 10:36:00 Menno

要聚合還是不聚合，那就是數據庫模式設計問題

回答

相關問題