在创建社交投票系统时，您是否应该在数据库中单独跟踪downvotes和upvotes？

Question

有SO，Digg，Reddit等等......

是否应该独立于upvotes跟踪数据库中的downvotes？或者他们应该只是根据用户的行为减少/增加一个“投票”字段而没有持续存在？

如何处理选票？

Answer 1

在SO上，票数增加+10，票数减少-2。为此，需要单独跟踪它们。一个有争议的答案很可能产生一些，并且只显示一个总数并不会有多大意义。所以我会说让他们分开。

Answer 2

我会将它们分开。有些问题有很多活动（上下），你真的很想识别它们。

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

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

Answer 3

取决于您对数据的处理方式。

如果你只想显示投票而不是我说你只使用一个字段。这就像论坛上一个帖子的观点数量。您希望查看获得最多点击次数的内容，但不会查看有人查看过的次数。

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

Answer 4

我可以建议您单独存储它们，甚至可以使用额外的数据来创建特定的up或downvote。谁知道，明天你可能会提出一个好主意，你需要这些额外的数据来实现它。

但是，有一种预先计算的字段（让我们称之为缓存）也是一件好事，无论何时提交上升或下调，都会更新。然后将使用此预先计算的字段呈现页面。这将增加响应时间并减轻DB上的负载。

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

Answer 5

考虑到您在社交投票网站的数据库中拥有的数据量，额外的int列用于存储下选票的额外空间可以忽略不计，因此您不会发疯。< / p>

Answer 6

好吧，假设SO有一个+10表示upvote而-2表示downvote，并且偶尔会重新计算，它需要独立存储它们。

否则，10个upvotes和5个downvotes的回答最初给你90分，如果它们没有单独存储，这将重新计算为50。

Answer 7

我会将它们分开，以便我可以单独查看它们。在社交方面，upvoting与downvoting非常不同，如果是我的话，我希望能够独立地看待它们。

Answer 8

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

Answer 9

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

Answer 10

我确信downvotes和upvotes是分开保存的，尽管可能有一个聚合字段可以保持计数。 SO允许您稍后更改投票（使downvote成为upvote），这就是为什么我相信每个用户都会记录投票。