預先計算的SQL屬性指南

Question

我經常會處理具有從其組成或子成員派生的屬性的聚合或父實體。 例如：

• 的byte_count和packet_count一個的TcpConnection對象從它的兩個組成的相同的屬性計算TcpStream對象，而這又是從它們的組成計算TcpPacket對象。

• 一個Invoices對象的total可能基本上是其組成InvoiceLineItems價格的SUM（），並InvoiceLineItems了一些運費，折扣和稅收邏輯。

當處理數百萬個數據包或數百萬個已開票的訂單項時（我希望！），按需計算這些派生屬性的速度（無論是在VIEW中還是在報表或Web界面等表示邏輯中更常見）通常會令人無法接受。

在性能問題迫使您動手之前，您如何決定是否將衍生屬性“提升”到預先計算的字段？

Answer 1

在性能折衷迫使我動手之前，我個人不會取消規范化（因為規范化的缺點太嚴重了，恕我直言），但是您可能還會考慮：

1. 便利性 ：例如，如果兩個不同的客戶端應用程序要計算相同的派生屬性，則它們都必須對查詢進行編碼以計算它們。 非規范化以一種更簡單的方式為兩個客戶端應用程序提供了派生屬性。
2. 隨時間推移的穩定性 ：例如，如果用於計算派生屬性的公式是可變的，則非規范化可以讓您在某個時間點捕獲和存儲派生值，因此以后的計算將永遠不會出錯
3. 更簡單的查詢 ：增加數據庫結構的復雜性可能意味着您的Select查詢在客戶端更簡單。
4. 性能 ：選擇對非規范化數據的查詢可以更快。

參考： 數據庫程序員：關於非規范化的爭論 。 一定要閱讀他的文章， 保持正確的非規范化值正確 -他的建議是使用觸發器。 這就帶來了需要權衡的非規范化。

Answer 2

基本上，您不需要。 您對性能的擔心會迫使您動手。

這是最好的答案，因為99％的時間，你不應該預先優化這樣的，最好是剛calc下它的飛行。

但是，客戶端應用程序開發人員帶着錯誤的先入之見來到服務器端是很普遍的，例如“ 按需計算...派生屬性...- 常常慢得令人無法接受 ”，這是不正確的。 。 此處正確的措詞是“ 很少會令人無法接受地緩慢 ”。

因此，除非您是此方面的專家（DB開發架構師等），否則您不應該從事過早的優化。 等到很明顯 ，就是已經被固定， 再看看前聚集。

Answer 3

數據必須是最新的，這實際上決定了如何實現它。

我將假設2個簡單狀態：當前或不當前。

• 當前：索引視圖，觸發器，存儲的proc以維護聚合表等
• 當前不是：Reporting Service快照，日志傳送/復制，數據倉庫等

就是說，我將使用與生產相同數量的數據進行開發，因此我對響應時間充滿信心。 您應該很少對代碼性能感到驚訝...