的性能數據庫設計注重信譽

Question

背景：

我試圖優化回報率完整的Ajax驅動的論壇。由於RoR已經不是完整的ajax站點的最佳平臺，我正試圖優化我的sql請求和存儲。

問題：

上崗的聲譽是基於簡單的喜歡/不喜歡從0-100％打算，而主要只有最後100票應該算加上所有其他職位的聲譽的10％誰參考/回覆該帖子。現在，將數值存儲在數據庫中以實現快速讀取的最有效方法是什麼？對於Post.reputation

嘗試的解決方案：

一）讀取所有對每個請求seperately連接。這將讀取巨大的連接表並計算連接。這是否會創建一個大的服務器負載，因爲它加載了很多條目，或者不是一個問題，因爲它基本上只有一個表？

b）根本不使用連接，但將信譽總和存儲在actual（喜歡+1，子喜歡+0.1）和potential（喜歡或不喜歡+1，喜歡或不喜歡+0.1） -dislike）。然後Post.reputation將是actual/potential。同時，我必須仍然使用users_posts的連接限制每個帖子投1票。在我看來，這將是具有最佳性能的解決方案，但有沒有一種方法可以通過額外的變量來實現100個投票計數限制？因爲我似乎幾乎放棄了關於選票順序的信息，這對於這一點很重要。

三）基本存儲所有聯接在一）但在數據庫中DB額外存儲的信譽值讀取和計算+寫它只要加入爲參照添加。在數據庫中多次存儲相同的信息是否是一種糟糕的方式？

問：

哪種解決方案是最聰明的存儲在我的數據庫，信息和訪問它快速/常？

Answer 1

最好的方法是（c）。很多時候，在RDBMS中，我們確實將冗餘信息存儲爲緩存以提高性能。

其他備註：

• 確保連接表對[POST_ID，ID]的索引。這將加速從連接表中選擇第100條記錄。
• 做更新的好地方是連接表模型的回調。這將確保更新在交易中。
• 在Post的has_many定義中指定：按照給出最新user_post的標準（最有可能是id desc）的順序。這將簡化其他查詢。

讓我知道你是否需要一些原理圖代碼。