每小时，每周，排名的数据库设计？答案

【问题标题】：Database design for hourly, weekly, ranking?每小时，每周，排名的数据库设计？
【发布时间】：2011-10-20 13:02:10
【问题描述】：

我一直在尝试找出一种处理此类排名系统的好方法。作为一个粗略的例子，我想查询一个 facebook 页面并获取每个帖子的喜欢和 cmets。然后，将基于时间间隔进行三个排名。举个简单的例子：

Hourly
- I pull all the posts updated within the last hour, and compare the # of likes/comments compared to my previous entry (the last pull being an hour prior).

Daily
- I pull down all posts within a 24 hours date range.  I compare the # of likes/comments compared to the previous entry. "Post X had 12 more likes and 40 more comments today compared to yesterday"

Weekly
- I pull down all posts within a week's range and do the same as above.  "Post X had no new likes, but 10 more comments added this week compared to last week"

就数据库表而言，什么是处理这个问题的好方法？有一张带有帖子（标题、cmets_previous、cmets_current、likes_previous、likes_current 等）的巨型表格是否有意义？

谢谢！

【问题讨论】：

标签： mysql ranking

【解决方案1】：

列：（PK）时间戳，（索引）pageid，计数。为喜欢的页面每小时设置一个新的时间戳。时间戳是 PK，这样您就不会从数据库中的聚集索引/页面布局中获得可怕的碎片。

如果您认为出于性能原因需要去规范化，您可以制作额外的每日和每月表格，这些表格是汇总汇总的。很可能，您可以通过在 time/pageid 组合上使用 where 子句，在不使用汇总表的情况下有效地生成所需的内容，从而只需一张表即可满足您的需求。

清除或保留您认为合适的旧数据。

澄清

当评论收到点赞时，请执行以下操作：

insert into likeRanking (concat(select left(now(),13), '00:00'), commentid, 1)
    on duplicate key update score = score + 1;

【讨论】：

感谢您的回答！由于我收集的是页面所有帖子的数据，而不是页面本身的数据，这对您的解决方案有什么影响吗？
您可以通过帖子和页面来完成。我认为结构的价值仍然存在。
对不起，我需要澄清一下。如果一个页面（或帖子）不断有新的 cmets 或喜欢，并且如果时间戳在那个时候不断更新，那么我如何能够访问一周前的数据？或者，您的意思是，当一个页面的 cmets 或喜欢的数量发生变化时，我会在表中创建一个具有相同 pageid（索引）但更新时间戳（pk）的新行？表中可以有相同的索引吗？
谢谢，我现在明白了:)

【解决方案2】：

我会这样做：

创建一个现在获取时间、现在获取时间和现在喜欢的表。

然后在那个时间的一个小时后，创建另一个表，该表现在获取时间，现在获取时间并现在喜欢，然后将其减去之前创建的表。然后删除另一个表并插入新表的新值。然后一个小时后，创建另一个表。

与每月和每年相同。

如果您还需要什么，请告诉我。

【讨论】：

每小时创建一个表？不，淘气。
感谢您的回答！这是处理此类情况的常用方法吗？我曾想过有六个表，然后简单地截断“以前的”表，但这似乎是浪费空间。在您的解决方案中，如果我理解正确，那么每个时间间隔（每小时、每天、每周）有两个表的唯一时间是数据提取时间本身？
没错。两个表只有在获取数据时才会存在。所以绝对不会浪费空间。另一个表在计算差异后每隔一小时、一天或一周由新表更新。不过，这只是我的想法。这就是我处理事情的方式。只是一个后续问题。你想让这个显示每次登录吗？
那么这很容易。只需获取注销时间。每次注销都会获取时间和日期。然后当用户登录时，你可以得到所有的喜欢，日期和时间然后得到两者的差异。应该就是这些了。