database - 在创建社交投票系统时，您是否应该在数据库中分别跟踪反对票和赞成票？

Question

使用 SO、Digg、Reddit 等...

是否应该独立于赞成票跟踪数据库中的反对票？或者他们应该只是有一个“投票”字段，根据用户所做的事情而减少/增加，而不需要持续存在？

应该如何处理选票？

score 5 · Accepted Answer

在 SO 上，赞成票获得+10，反对票获得-2。为此，需要单独跟踪它们。一个有争议的答案很可能会产生几个，而仅仅显示一个总数并没有多大意义。所以我会说让他们分开。

score 2 · Accepted Answer

我会把它们分开。有些问题有很多活动（上下），你真的很想找出那些。

即使您现在对差异不感兴趣，表中的额外字段也不会那么昂贵，因此将其分开也没有什么坏处。因为如果你以后想添加它，如果不单独存储，你就无法检索数据。

我还假设 SO 对 CW 和非 CW 条目分别进行投票。因为如果问题稍后更改为 CW，即使重新计算，也会保留原始获得/丢失的代表。

score 1 · Accepted Answer

取决于您希望如何处理您的数据。

如果您只想显示选票而不是我说您只使用一个字段。这就像论坛上某个主题的观看次数。您想查看点击次数最多的内容，而不是有人查看了多少次。

SO上的投票系统有点复杂。由于他们可以取消来自特定用户的所有投票，因此他们必须跟踪谁投票支持/反对什么。我认为，这写在另一个表中，但是因为每次有人查看问题时重新计算所有投票的成本很高，所以他们将计算值保留在字段中，每当有人投票时更改它。

score 1 · Accepted Answer

我可以建议您将它们分开存储，甚至可能包含编写特定赞成或反对票的额外数据。谁知道呢，明天你可能会想出一个好主意，而你将需要这些额外的数据来实现它。

但最好有一种预先计算的字段（我们称之为缓存），只要提交赞成票或反对票，它就会更新。然后将使用此预先计算的字段呈现页面。这将增加响应时间并减轻 DB 上的负载。

如果立即重新计算值的成本太高，您可以考虑运行一些调度程序任务（每小时一次？），这将处理最新的投票并重新计算缓存的值。

score 1 · Accepted Answer

考虑到社交投票网站数据库中的数据量，用于存储否决票的额外int列的额外空间可以忽略不计，所以你会疯了。

score 0 · Accepted Answer

好吧，鉴于 SO 有 +10 表示赞成票和 -2 表示反对票，并且偶尔会进行重新计算，因此需要独立存储它们。

否则，最初给您 90 分的 10 个赞成票和 5 个反对票的答案，如果它们没有单独存储，这将重新计算为 50。

score 0 · Accepted Answer

我会将它们分开，以便我可以单独查看它们。在社会上，赞成与反对是非常不同的，如果是我，我希望能够独立地看待它们。

score 0 · Accepted Answer

出于一个非常简单的原因，绝对是分开的。明天你会想做一些额外的事情，需要这些信息（例如某种报告或图表）。除了单独保存它们之外，您不会花费任何费用。

score 0 · Accepted Answer

因为人们通常可以投票一次，并且（例如在 SO 中）可以取消他们的投票，所以您需要知道谁投票、在什么时间、什么投票以及在哪个项目上投票。

score 0 · Accepted Answer

我敢肯定，downvotes 和 upvotes 是分开保存的，尽管可能有一个聚合字段来保持计数。SO 可以让您稍后更改投票（使反对票成为赞成票），这就是为什么我相信每个用户也会记录投票。

10 回答 10