我想添加一個非常簡單的點系統到一個網站。在我的SQL數據庫中，有一張用於獎勵積分的表格，因爲管理員可以增加用戶的積分數量以及積分增加的基本原理。所以，簡化一點，這個表格包含了每次管理員獎勵積分的獎勵數量，理由和用戶ID。到現在爲止還挺好。點系統的高效數據庫模型？
但是，網站上有10個用戶組競爭總分最高點。單個用戶羣的點數可輕鬆達到15000個，因爲該網站已經有超過10 000個成員（當然，大多數是不活躍的）。我想要一個排行榜來展示競爭的用戶組和他們的總分，但是我擔心在實施這個系統時，總結積分要花很長時間才能完成。以下是問題：我應該在什麼級別（如果有的話）將點聚合保存在數據庫中？我應該在用戶表中爲每個用戶的總積分添加一個字段，然後爲用戶組排行榜進行總結？或者我應該爲每個更新的每個用戶組設置一個聚合字段，每次將點數添加到單個用戶？在實際實施系統之前，我想先了解需要多長時間才能完成這些工作，因爲執行不當會影響數千個用戶，而且我沒有太多的實際經驗數據庫。
老實說，您的聚合仍然可能在少於一秒鐘內計算，少於10k行 - 您應該將操作數據庫原子化並存儲每個點事務並在查詢時計算聚合。如果你真的想，你可以預先計算你的聚合成一個物化視圖，但我真的不認爲你需要。
你可以創建一個條款
refresh fast start with sydate
next sysdate + 1/24
- 要已將其每小時刷新物化視圖。
您不會有實時聚合數據（它可能會關閉一個小時），但如果數據變得很大，它可能會提高聚合查詢的性能。由於您的數據是現在，我甚至不打擾它 - 但你的表現應該沒問題。
編輯：不知道爲什麼我被低估。我認爲這比在表格中存儲聚合更好。
這取決於你的硬件，但總結數千行應該沒有問題。一般來說，除非你絕對需要，你應該避免總結所有的用戶分數。我會建議添加一個rolup表，它將存儲每個組的總分，然後每晚運行一個cron驗證總分（基本上是進行總結，然後存儲絕對正確的值）。
我建議在您的表格中添加記錄點數和獎勵原因。另外，將每位用戶的總分分別存儲起來，並在插入日誌表的同時將其更新，並將每個用戶的總分數插入另一個表中。這應該適合您的活動水平。如果過於引起爭議，您也可以對總體分數進行異步更新，但應該沒問題。
爲用戶保留點總數是一個不錯的主意。插入分數調整表時，只更新用戶總數。這是更高效的，因爲您的應用程序對於相對較少的寫入有很多讀取。唯一的注意事項是確保使用原子事務來確保插入和求和都發生。此外，通過運行全部數據來檢查用戶總數的夜間工作也是一個體面的想法。