我有一個項目計算關於用戶性能的'統計'數量，然後顯示給他們。所有這些統計數據最終都來自記錄用戶與網站互動的「互動」大表。目前，所有這些統計數據都是通過查看這些數據來計算的。我們廣泛使用持久緩存來保持這些事情的快速進行。用戶統計：「interative calculation」或批量計算+高速緩存
我們正在考慮將統計值存儲在數據庫中的「迭代設計」中，在記錄每次交互時，我們根據每個分數對交互作用的貢獻更新值，所以我們基本上迭代更新值。 （現在我們只是骯髒的緩存）。
我看到了一些麻煩與迭代設計，因爲它意味着我們有這些冗餘，可能出存儲在我們的數據庫中，這使得增加新的統計困難，同步信息和手段上的每一次互動日誌更多的工作。但好處是它簡化了統計數據查找以單數據庫命中！
的東西在這個迭代設計提出了報警鈴我，但我不能否認的潛在節省時間的效益。我應該服從這種直覺嗎，還是繼續做下去？
當我在做數據庫設計時，儘量避免存儲冗餘數據。 （畢竟，這是數據庫規範化的對象）。計算的列和視圖都可以 - 這些由SQL服務器自動管理和更新。就個人而言，在使用數據庫進行緩存之前，我會傾向於其他途徑（SQL查詢是否真的是需要提高性能的部分？我可以通過使用SQL視圖來簡化應用程序中的事情嗎？等等）
當你說操縱數據，你做什麼操作是如此昂貴？你的意思是插入/更新/刪除？如果您對統計數據的使用是寫密集型的，則可以考慮刪除索引以加快數據更改速度。
沒有實際的數據庫操作，我只是想拉200行左右，按摩我想要的東西（有時它的所有獨特apparences的特定值，有時它的行數匹配的東西，等等數量的計數）。這些都不涉及數據庫寫入，只有當這些東西被記錄（目前！）。 – Chris
在這種情況下，您最好添加索引，而不是刪除它們。 =）但是，在你做之前，性能問題是否來自多個數據庫命中？或者查詢運行緩慢？或者只是返回的結果數量？如果問題來自有多個數據庫命中或者計算/提取所需數據的方式，則可以通過將邏輯移動到視圖/公用表表達式（SQL Server）/用戶定義的函數/存儲過程。我並不是說在數據庫中緩存數據是錯誤的，只是這對我來說是最後的選擇。 – RMorrisey
會觸發幫助下，你可以再做計算，每當新的數據進來，從而導致沒有陳舊的數據。
這隻會有助於讀取遠遠高於寫入。如果我爲每次讀取做2次寫入，那麼這將是一個糟糕的設計。
你在做什麼，將是有益的
觸發器/信號將是我如何觸發迭代更新！ 只有當數據從用戶交互記錄時纔會發生寫入（此刻）。統計計算不涉及寫入。所以整體來說它是一個閱讀密集型應用 – Chris
計算刀片式的基礎上更多的細節肯定是要走的道路，恕我直言。
爲了掩飾的，比如，不能夠立即產生新的統計（因爲你沒有計算數據）的問題，您可以：
或
根據您的緩存模型，這些統計信息可能不同步，或者可能不同步。如果是觸發器，則立即發生（插入tblFoo更新tblFooStats）;但你可以根據需要檢索它。
我認爲唯一真正的風險是如上所述：不能立即添加新的統計/計算。如果你覆蓋這個，生活應該很好。
某些數字： 每個統計量都是從幾百行和幾個db命中計算而來的。儘管被稱爲統計數據，但數字處理並不重要，真正的性能瓶頸在操縱數據。 – Chris