具有每小时、每天、每月值或单独表的 MySQL 单表？答案

【问题标题】：MySQL single table with hourly, daily, monthly values, or separate tables?具有每小时、每天、每月值或单独表的 MySQL 单表？
【发布时间】：2022-06-25 07:04:01
【问题描述】：

在处理数据值时，我应该创建一个单独的表来存储每小时值以及汇总的每日/每月值，还是应该为这些创建单独的表？

我想多桌会是最好的选择，但我在这里完全是个业余爱好者。这听起来像是可以提高性能并可能提高维护的东西，但我也想知道这是否会有所作为。最后，拥有 3-4 个表对 1 个也可能会导致一些我想像的维护问题。

所以基本上，一个 values_table 包含：

id     value    datetime                 range
1      33       2022-05-13 11:00:00      hourly
2      54       2022-05-13 12:00:00      hourly
3      840      2022-05-13               daily
...

对

hourly_values_table 包含：

id     value    datetime
1      33       2022-05-13 11:00:00
2      54       2022-05-13 12:00:00
...

还有一个daily_values_table包含：

id     value    datetime
1      840      2022-05-13
...

处理这个问题的正确方法是什么？

【问题讨论】：

只需使用完整精确的时间戳存储您的数据，然后根据需要按天、小时或分钟生成报告。
我的印象是，很多人不愿意使用关系数据库来完成它们的设计目的（聚合信息拆分成表格）。如果您将所有内容打包在一个表中，您计划使用哪些 SQL 查询和索引来计算聚合值？
补充@TimBiegeleisen 所说的内容，使用您的任何一种方法，您基本上都是通过存储“冗余”数据来进行非规范化。这就是可能导致维护问题的原因。它可以是一个选项，但仅出于性能原因。至少，不要将“缓存”数据与原始数据混在一起。
@TimBiegeleisen 我关心的是性能。假设我正在处理数百万个值，在这种情况下，存储聚合数据将是首选，不是吗？
视情况而定。派生数据通常不应该长期存储，因为它是从另一个表派生的。因此，当另一个表中的数据发生更改时，您的派生数据会立即变得陈旧。正确索引的表中的数百万个值是没有问题的。

标签： mysql database database-normalization

【解决方案1】：

您的每小时数据是数据仓库的“事实”表”。我认为，它是“持续”写入的，从未更新。

“汇总表”对性能很有用。通常只需要 1 个。例如，“每日”表可让您减少 24 倍。从该表中，您可以合理有效地获取每周、每月或任何任意日期范围。（我需要更多指标，更好地了解您存储的数据类型，以便更确定我在说什么。）

我讨论将 MySQL 用于DW 和Summary tables

当然，纯粹主义者争论“冗余”数据的存储。但是当你得到十亿行时，你真的需要汇总表来避免性能瓶颈。

至于Fact表或Summary表中的数据保存多长时间，我经常建议：

使用Partitioning 快速清除旧数据（例如一个月后），从而节省磁盘空间；
“永远”保留汇总表，因为它们“很小”。

【讨论】：

【解决方案2】：

我不明白你的目的或方法？

你必须从数据库的目的开始？您要存储哪些数据，为什么？

通过阅读您的描述，我无法判断这些数据是否应该与某个人相关联，还是出于会计目的？没有上下文。

从数据库的用途开始，这将识别表/名称，然后揭示结构和关系。并转到我在这里的帖子进行澄清，这在概念上可能会有所帮助。 Link

【讨论】：