MySQL数据库表结构效率建议

Question

我们正在设计一个MySQL表来跟踪每天10000个推特账户的追随者数量。我们一直在努力找出存储这些数据的最有效的方法。我们考虑的两个方案是：

1) OPTION 1 - Table with rows: Twitter ID, Month, Day1, Day2, Day3, etc. where each day would contain the number of followers for that account for each day of the specified month
2) OPTION 2 - Table with rows: Twitter ID, Day, Followers

选项1的行数大约是选项2的1/30。从性能的角度来看，我不确定的是列数少还是行数少是更好。

就我们将使用的查询而言，我们只希望能够查询数据，以获得特定Twitter帐户在任意时间范围内的关注者数量。

我希望能就哪种方法更好以及原因提出建议。此外，如果有比我提出的更好的选择，请随时建议。

提前感谢您的帮助！

Answer 1

选项2，毫无疑问。

想象一下，尝试使用每个选项编写一个查询。让我们给出选项1的最佳情况:我们知道我们想要一个月中所有31天的总和。使用选项1的THen查询为：

select twitterid, day1+day2+day3+day4+day5+day6+day7+day8+day9+day10
 +day11+day12+day13+day14+day15+day16+day17+day18+day19+day20
 +day21+day22+day23+day24+day15+day26+day27+day28+day29+day30
 +day31 as total
from table1
where month='2010-12';

select twitterid, sum(day) as total
from table2
where date between '2010-12-01' and '2010-12-31'
group by twitterid;

第二个在我看来要容易得多。如果您不这么认为，请告诉我您是否立即注意到option 1版本中的错误，以及您是否确信没有程序员会犯这样的错误。

现在，假设需求稍有变化，有人想要一周的总需求。对于第二个版本，这很容易:给出一个描述该周的日期范围。在动态构建查询时很容易做到这一点: JUst请求开始日期，并在此基础上添加6天作为结束日期。但是对于第一个版本，你打算怎么做呢？您必须找出一个月中的哪些天在该周内，并更改检索到的字段列表。一周可能跨越两个日历月。这将是一个巨大的痛苦。

至于性能:当然，检索更多的行需要更多的时间。但是，较长的行也需要更多的时间来检索。关于数据库设计的第一课:当您甚至没有很好的理由相信存在问题时，不要抛出规范化来进行微优化。首先构建一个规范化的数据库。然后，如果发现存在性能问题，请在之后对其进行调优。很有可能，你可以买一个更快的硬盘驱动器，比程序员花一天的时间在不必要的复杂查询中查找错误的成本要少得多。

Answer 2

当然，这取决于您要执行的查询-但除非每个查询都需要该月的31天，否则对于您的操作数据，请使用选项2。

• 从逻辑的角度来看更好(比如以后你不想要每30个日历天的查询，而是最近X天的查询)
• 写入也更好(只用2个字段更新1行，而不是覆盖所有字段)。
• 您可以随时优化(想到分区)
• 您的数据仓库仍然可以针对长期聚合统计数据进行优化。

Answer 3

使用选项2。选项1将是查询的噩梦。MySQL对查询中的日期范围有很好的支持，所以每天只有行是最容易的。