以下方案可以與StackExchange信譽系統進行比較。我想知道哪個是性能和可伸縮性方面最好的方法。獎勵系統的數據庫設計 - 即時計數或使用單獨/連接表？
場景：我有一個遊戲網站，我需要爲用戶頒發獎章。每枚獎牌明顯具有自己的要求。例如：打一定數量的比賽;連勝;一場比賽的前1分;等等。
選項1：如果在註冊新匹配時滿足條件，則將記錄存儲在連接表（users_medals）上。起初這會更簡單快捷，但是很難追蹤未來的狀況變化（例如：增加某些獎章所需的勝利數量）。
選項2：每次用戶瀏覽用戶配置文件時，不要存儲任何關係並執行所有計算。它可以很容易地處理條件的變化，但用戶和獎牌越多，顯示用戶信息的速度越慢，或用戶名單越差。
首先我同意已經獲得獎牌的miraculixx應該留在用戶身上。因此，你應該堅持與用戶記錄中贏得獎牌在任何一個關節表或使用一個方法，我使用的超速應用顯着：
我絕對不會用你的路線2，因爲隨着用戶基數的增加，你會遇到非常糟糕的性能問題。
現在，當用戶查看他們的個人資料時，您的應用程序將使用Id的獎牌在列上進行迭代，並可能從幾張不同的獎牌中拿出幾張不同的獎牌並顯示它們（毫秒），而不是計算出什麼他贏得的獎牌（在大桌子上很慢）。您的用戶可以拉取歷史記錄，您可以創建統計數據等。
如果您更改達到某些目標的標準，那麼以前的標準達到該標準的現有用戶會獲得他們的獎牌並且新用戶需要符合新標準。如果你不希望這個拿走獎牌（人們會變得非常瘋狂;-)）
恕我直言，提供可擴展但快速解決方案的最佳方法是緩存計算值。我會分解成多個表（或任何nosql數據庫中調用的東西），但計算更改並堅持它們 - 重要的是快速。唯一與用戶有關的缺點是某些不一致性會被包含在術語eventual consistency中。取決於你的用戶會容忍什麼。
我認爲最好的例子，如何去思考這樣的問題和解決方案是研究如何會有人使用Redis的設計嘰嘰喳喳的解決方案，請參閱http://redis.io/topics/twitter-clone
選項3：運行sceduled任務，以檢測新的獎牌和堅持的結果。關於選項2的 –
- 關於變化的條件，你真的會拿走贏得的獎牌嗎？ – miraculixx
好的，在某些情況下，我將不得不這樣做。改變標準的一個常見原因是平衡事情。如果老用戶有更多的獎牌，這對新用戶來說是不公平的，因爲在新用戶加入之前，要求變得更加容易。但是，是的，它應該至少有一個選擇，以保持舊的獎勵打算。 – rzb