Database design 在数据库中存储主动更新的字段

我有一个数据库，其中一个表存储文章。对于每一篇文章，我都需要存储它的浏览次数。现在，我的想法是将该值存储在数据库中，并在每次有人访问带有该文章的页面时进行更新，我现在正在考虑两种选择：

在表

articles

中创建一列

views

，并对其进行更新

创建一个单独的表

view\u count

，其中FK指针指向文章和该文章的数字视图

我的问题是：这两种方法在速度上有什么区别吗？为什么？还有更好的选择吗

我使用的数据库是PostgreSQL

---

注意，我没有考虑在单独的文件中累积这些值的不同方式，在数据库之外和以后插入，因为i）我们没有得到那么多的点击ii）minor中的功能，如果它需要这样的麻烦，我们宁愿放弃它，并为此使用其他服务。

如果

文章

表得到了大量的写入，那么更新列可能会慢一点，因为在写作

使用一个单独的表只会稍微慢一点/重一点，但在更新方面是最轻的。但是，在加载写操作之后，您可以轻松地重建该表，而不会造成太多性能损失，因为它将是一个非常轻的表

---

如果您的数据库负载不高，我会选择简单的方式添加一个列。

两个方案的差异非常微妙，我是这样看的：

同一表格

• 将它保存在同一个表中将允许您以更低的成本检索它
• 更新可能会锁定数据库中队列中其他查询需要减慢速度的部分
• 使表更宽可增加I/O（对于表扫描，它总是增加I/O，但对于索引查找，它并不是那么简单——当记录大小大于文件系统的块大小时，即使索引查找也必须多做2倍的I/O；或者，

  n

  x更多的I/O，这取决于记录大小/块大小，如果记录大小远小于块大小，则ef）索引查找的效果取决于磁盘上数据的查询类型/顺序-如果从同一块中选择记录，您将感觉到性能受到影响，如果选择稀疏数据，您将感觉不到）

单独的表格

• 更新将在更小的表上进行，因此I/O更少（根据隔离级别，检查外键可能仍然需要锁，但应该更短，因为I/O更少）
• 检索项目的数据需要联接，这将增加I/O
• 如果视图计数是一项新功能，但在大多数其他记录中不存在，则也可以节省空间，即使join可能会增加所需的I/O，这可能会提供更好的性能

注释：

---

注释适用，但很微妙：记录大小可能不会显著影响所有查询。使用单独的表减少I/O的好处可能无法察觉。

我还有一种方法，在当天晚些时候或网站流量太少时进行更新。

---

我会这样做，当任何用户阅读文章时，用户id将存储在一个新表中，稍后通过脚本我可以更新用户阅读文章的次数。

这仍然属于单独的表选项。由于关系的基数为1:0,1，我看不到使用v的好处查看列位于两个位置，其中一个位置定期更新。@maksymko，谢谢-我更新了一点答案，关于索引查找，旧文本不够精确。