Question

我们正在设计一个MySQL表，以便每天跟踪10,000个Twitter帐户的关注者数量。我们一直在努力找出存储这些数据的最有效方法。我们考虑的两个选项是：

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减少约30倍。从性能角度来看，我不确定的是，是否优先选择较少的列或较少的行。

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

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

提前感谢您的帮助！

Answer 1

选项2，毫无疑问。

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

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;

第二种看起来对我来说更容易。如果您不这么认为，请告诉我您是否立即注意到选项1版本中的错误，并且如果您确信没有程序员会出现这样的错误。

现在想象一下，这些要求会略有变化，而有人希望总数达到一周。使用第二个版本，这很容易：给出描述该周的日期范围。这可以在动态构建查询时轻松完成：JUst要求开始日期并在结束日期添加6天。但是对于第一个版本，你打算做什么？您必须弄清楚该周的哪几天会下降并更改检索到的字段列表。这一周可能跨越两个日历月。这将是一个巨大的痛苦。

关于性能：当然，更多行需要更多时间来检索。但是更长的行也需要更多的时间来检索。关于数据库设计的第1课：当你甚至没有充分的理由相信存在问题时，不要抛弃规范化来进行微优化。首先构建规范化数据库。然后，如果事实证明存在性能问题，请在之后进行调整。可能的是，你可以购买一个更快的硬盘驱动器，而不是花费一天程序员在不必要的复杂查询中发现错误的时间。

Answer 2

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

从逻辑角度来看，这样做会更好（稍后说你不希望每个“30个日历日”查询，但是“最后X天”）
写作也更好（仅限用2个字段更新1行而不是覆盖所有字段）。
您可以随时优化（想到分区）
您的数据仓库仍可针对长期汇总统计信息进行优化。

Answer 3

使用选项2.选项1将成为查询的噩梦。 MySQL对查询中的日期范围有很好的支持，因此最简单的就是每天都有行。

Answer 4

我会说选项2，但您可能希望为主键添加字段以加快查询速度。如果那个主键是一个整数值，那就更好了。

Answer 5

选项2肯定（在Twitter ID和Day上有两列唯一键/约束）。

选项1将是令人遗憾的。

MySQL数据库表结构效率建议

5 个答案: