我需要能夠從SQL Server和Sybase數據庫以這種格式訪問數據（date, product是關鍵）。我是否應該在表格中計算或存儲這些累計和？
date, product, dailyProfit, monthlyCumulativeprofit, yearlyCumulativeProfit
目前，一期工程我接手有這樣的表，其中dailyProfits得到更新，添加，刪除......其結果是，它似乎像現有的代碼破壞了每月累計利潤，以及作爲年度累計利潤。
爲了解決這個問題，而不是在代碼挖+恢復表的完整性，我可以有一個表，如：
date, product, dailyProfit
這將接受插入，更新，刪除和使用一些機制（觸發？或者是有風險的，因爲這個小表包含的平均值爲300萬行？），這將給我一個包含累積和的同步視圖，以更自動化和可信的方式...
您對此有何評論？
只要可行，請避免存儲冗餘數據。如果您同時存儲單個數值和總數，則可能造成總數可能與單個數值的總和不匹配。這可能會導致一些神祕的錯誤，其中讀取各個值的函數與使用存儲的總和的函數的結果不同。如果幸運的話，有人會注意到屏幕A上的值與屏幕B上的值不同，您可以調查並修復它。但是，如果情況更復雜，就像你使用一組值來選擇標準，另一組值用於顯示，可能沒有人會注意到。
保持值同步可能是一個主要的編程頭痛，這取決於關係是什麼。如果幸運的話，您可以設置一些觸發器，每次添加，更改或刪除單個值時自動更新總數，因此至少只能在一個位置完成。
但這裏的關鍵詞是「每當實際」。舉一個簡單的例子：每次用戶訪問他的銀行賬戶時，他可能都希望看到餘額。如果要顯示自從他在多年前開設賬戶以來每次交易必須加起來，那麼這可能是一個性能殺手。
因此，當你必須存儲冗餘總計時，但只有在必要時才存儲。如果您必須存儲冗餘總計，請儘可能保留儘可能少的級別。我不會存儲每日總計，每週總計，每月總計和年度總計。我會嘗試爲合計挑選一個級別並保持這一級別。就像你可以重新計算每天和每週總計。也許保持每月，然後你可以計算每年加起來12個月。或者，也許只是爲了長期計算而保持年度，並且一切都在飛行中計算。這一切都取決於你有多少記錄和你需要什麼輸出。但是每一個額外的總數都是保持同步的一件事，因此還有一個潛在的問題。
這取決於。如果您經常請求累積和，那麼存儲它們會是一個好主意，因爲用每個請求計算它們都會佔用大量資源。
您可以設置觸發器，以便在增加和減少刪除時增加累積值。在更新時，您需要更新。
出於同樣的原因，網絡論壇通常每個用戶都有帖子數量，儘管帖子當然可以在每次請求時計數（這會對性能產生巨大影響）。觸發器只是在添加新帖子時增加計數器，在刪除帖子時減少。
這實際上取決於你使用的數據庫和數據使用信息。預先彙總的數據可能導致過時的信息，因此建議謹慎使用。只要有可能，「即時」計算應該是首選（特別是如果性能不是問題）。
這裏有幾個更多的選項來探索。索引/物化視圖（link）或使用M-Olap多維數據集預先聚合信息。