在數據庫中存儲主動更新的字段

Question

我有一個存儲文章表的數據庫。對於每篇文章，我需要存儲查看次數。現在，我的想法是這個值存儲在數據庫中更新，每次有人訪問該網頁與文章，我現在正在考慮兩種選擇：

1. 在表articles創建一個列views和更新。
2. 創建一個單獨的表view_count與指向文章的FK指針和該文章的編號視圖。

我的問題是：這兩種方法在速度方面有什麼區別，爲什麼？有沒有更好的選擇？

我使用的數據庫是PostgreSQL。

注意，那我不考慮積累在不同的文件中這些值，數據庫之外，後來插入，因爲我），我們不小的獲得儘可能多的命中II）的功能，如果它會的方式不同需要這樣一個麻煩，我們寧願放棄它，並使用其他服務。

Answer 1

的兩項提案的差異是相當微妙的，這裏就是我看到他們：

同桌

• 保持它在同一個表將允許您以更低的成本
檢索
• 更新可能會鎖定隊列中其他查詢需要減慢的部分數據庫
• 使表更廣泛地增加I/O（它總是會增加表掃描的I/O，但對於索引loo kups並不是那麼直截了當 - 當記錄容量變得更大時，文件系統的塊大小，那麼即使索引查找也必須再做兩次I/O;或n x更多I/O取決於記錄大小/塊大小，如果記錄大小遠小於塊大小，則索引查找的效果取決於查詢的類型/磁盤上數據的順序 - if從同一個塊中選擇記錄，你會覺得對性能的影響，如果選擇稀疏數據，你會不會覺得它）

單獨的表

• 更新將在一個較小的表發生，所以更少的I/O（根據隔離級別，鎖可能仍然需要檢查外鍵，但由於I/O較少，鎖應該更短）
• 檢索一篇文章的數據需要一個連接，這將增加I/O
• 如果查看計數是一個新功能不存在於大多數其他記錄上，您還節省了空間，即使連接可能會增加所需的I/O ，這可能會提供更好的性能

注意：
註釋適用，但有微妙：記錄大小可能不會得到顯著的影響來影響所有查詢。使用單獨的表格減少I/O的好處可能無法察覺。

Answer 2

如果articles表獲得大量的寫入比更新列可能會慢一點，因爲在寫入時會發生表鎖。

使用單獨的表格只是讀取速度較慢/較重，但在更新方面最輕。但是在寫入大量文件之後，您可以輕鬆地重建表格而不會有太多的性能損失，因爲它會是一張非常輕鬆的表格。

如果你的數據庫沒有高負載，那麼我會輕鬆選擇添加一列。

Answer 3

我還有一種方法，我在那裏稍後進行更新，或者當網站的流量太少時。 我會以這種方式完成這項工作，任何用戶在閱讀文章時都會將用戶標識存儲在新表中，稍後通過腳本可以更新用戶閱讀文章的次數。