關於預先計算的SQL屬性的指導

通常我會處理具有派生於其組成成員或子成員的屬性的聚合或父實體。例如：關於預先計算的SQL屬性的指導

的byte_count和TcpConnection對象從計算其兩個組成TcpStream對象，而這又是從其構成TcpPacket對象計算出來的相同的屬性的packet_count。
的Invoices對象可能有一個total也就是它的組成InvoiceLineItems'價格SUM（），有一點運費，折扣和稅收邏輯拋出。

當與處理數百萬個數據包或數百萬個開具發票的訂單項（我希望！），按需計算這些派生屬性 - 無論是在VIEW中還是更常用的演示邏輯（如報表或Web界面） - 往往令人無法接受地緩慢。

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

2010-02-05 pilcrow

爲什麼這是社區Wiki？ – RBarryYoung 2010-02-05 21:53:50

@RBarryYoung，我期望這個問題的答案更像是「來自經驗的智慧」，而不是「一個明顯正確的解決方案」。 – pilcrow 2010-02-05 22:50:11

pilcrow - 如果你希望人們根據他們的經驗*閱讀相對技術性的解釋*，你不應該把它變成一個社區維基。現在，如果問題是「您認爲SQL Server是否具有預計算字段的良好實現」或某種純粹的意見，那麼社區wiki將更合適。很多這裏最好的貢獻者（尤其是那些剛剛建立自己聲譽的新人）都是真正的角逐者！ – 2010-02-07 15:41:03

我個人不會反規範化直到性能權衡迫使我的手（因爲反向標準化的缺點是過於激烈恕我直言），但你也可以考慮：

便利：例如如果兩個不同的客戶端應用程序想要計算相同的派生屬性，則它們都必須對查詢進行編碼以計算它們。非規範化以更簡單的方式向客戶端應用程序提供派生屬性。
穩定性隨着時間的推移：例如如果用於計算派生屬性的公式可以更改，則非規範化允許您在某個時間點捕獲並存儲派生值，以便將來的計算永遠不會出錯
更簡單的查詢：向DB結構添加複雜性意味着您的Select查詢在客戶端更簡單。
性能：在非規格化數據上選擇查詢可以更快。

Ref：The Database Programmer: The Argument for Denormalization。請務必閱讀他的文章保持非規範化值正確 - 他的建議是使用觸發器。這帶來了反向非規範化需要的這種折衷。

來源

2010-02-07 15:34:30

+1 - 非常好的答案 – 2010-02-07 15:41:26

基本上，你沒有。你留下的表現擔憂迫使你的手。

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

然而，這是很常見的客戶端應用程序開發人員前來服務器端有誤的偏見，如「點播的...派生屬性計算... - 是往往太慢 「，這只是不正確的。在這裏正確的措辭將是「是很少難以接受的慢」。因此，除非您是這方面的專家（數據庫開發架構師等），否則您不應該參與過早的優化。等到它是明顯那是必須要修復的，然後看看預聚合。

來源

2010-02-05 21:51:11 RBarryYoung

當前的數據必須確定如何實現它，真的。

我會假設2個簡單的狀態：當前或不是當前。

電流：索引視圖，觸發器，存儲的特效，以保持總表等
沒有電流：報告服務快照，日誌傳送/複製，數據倉庫等

這就是說，我會制定針對與我所使用的相同數量的數據，所以我對響應時間有一定的信心。你應該很少會對你的代碼性能感到驚訝......

來源

2010-02-05 21:51:53 gbn

關於預先計算的SQL屬性的指導

回答

相關問題