【发布时间】：2009-04-09 08:07:09
【问题描述】：
使用 SO、Digg、Reddit 等...
是否应该独立于赞成票跟踪数据库中的反对票？或者他们应该只是有一个“投票”字段，该字段根据用户所做的事情而递减/递增，而不会持续存在？
应该如何处理选票？
【问题讨论】：
标签： database social-networking voting
【发布时间】：2009-04-09 08:07:09
【问题描述】：
在 SO 上，赞成票获得 +10，反对票获得 -2。为此，需要单独跟踪它们。一个有争议的答案很可能会产生几个，而仅仅显示一个总数并没有多大意义。所以我会说让它们分开。
【讨论】：
-
+1，完全正确。还需要停止重新投票和取消投票。
我会把它们分开。有些问题有很多活动（上下），你真的很想找出这些问题。
即使您现在对差异不感兴趣，表中的额外字段也不会那么昂贵，因此将其分开也没有什么坏处。因为如果以后要添加，如果不单独存储，就无法取回数据。
我还假设 SO 为 CW 和非 CW 条目保留单独的投票。因为如果问题稍后更改为 CW，即使重新计算，也会保留原始获得/失去的代表。
【讨论】：
取决于您希望如何处理您的数据。
如果您只想显示选票而不是我说您只使用一个字段。这就像论坛上某个主题的观看次数。您想查看点击次数最多的内容，而不是查看用户查看的次数。
SO 上的投票系统有点复杂。由于他们可以取消特定用户的所有投票，因此他们必须跟踪谁投票支持/反对what。我认为这是写在另一个表中的，但是因为每次有人查看问题时重新计算所有投票的成本很高，所以他们将计算后的值保留在一个字段中，并在有人投票时更改它。
【讨论】：
我可以建议您将它们分开存储，甚至可能包含编写特定赞成或反对票的额外数据。谁知道呢，你明天可能会想出一个好主意，而你将需要这些额外的数据来实现它。
但最好有一种预先计算的字段（我们称之为缓存），它会在提交赞成票或反对票时更新。然后将使用此预先计算的字段呈现页面。这将增加响应时间并减少 DB 上的负载。
如果立即重新计算值的成本太高，您可以考虑运行一些调度程序任务（每小时一次？），这将处理最新的投票并重新计算缓存的值。
【讨论】：
考虑到社交投票网站数据库中的数据量，额外的int 列用于存储否决票的额外空间可以忽略不计，所以你不这样做会很疯狂。
【讨论】：
-
您实际上可以使用一点，而不是 int。随着时间的推移，它实际上可以节省大量空间。您也不需要另一列。如果表中有给定用户的条目，则该用户已投票。值 0 可以解释为反对票，值 1 可以解释为赞成票。
好吧，鉴于 SO 有 +10 表示赞成票和 -2 表示反对票，并且偶尔会重新计算，因此需要独立存储它们。
否则，10 个赞成票和 5 个反对票的答案原本给您 90 分，如果它们不单独存储，这将重新计算为 50。
【讨论】：
我会将它们分开，以便我可以单独查看它们。在社交方面，赞成与反对是非常不同的，如果是我，我希望能够独立地看待它们。
【讨论】：
出于一个非常简单的原因，肯定是分开的。明天你会想做一些额外的事情，需要这些信息（例如某种报告或图表）。除了将它们分开存放之外，您无需支付任何费用。
【讨论】：
由于人们通常可以投票一次，并且（例如在 SO 中）可以取消他们的投票，因此您需要知道谁投票、在什么时间、什么投票以及针对哪个项目投票。
【讨论】：
我确信反对票和赞成票是分开保存的，尽管可能有一个聚合字段来保存计数。 SO 允许您稍后更改投票（将反对票变为赞成票），这就是为什么我相信也会为每个用户记录投票。
【讨论】：