我们正在重构我们的数据库,每天将向数据库添加大约 100.000 行。 现在每行都包含一个日期字段 (yy-mm-dd),因此今天我们在表中输入了日期“2013-11-29”100.000 次。
由于我们不存储时间,因此将日期分解到一个单独的表中并使用它的 id 是否有意义?
这里面有一个权衡。如果我们将其分解,我们将在稍后要查看记录时使用的查询中添加另一个 JOIN。我们在查询信息时已经连接了3张表,数据库包含大约1000万条条目。
有什么想法吗?数据库变得越来越大,因此我们需要考虑磁盘空间以及预制。
最佳答案
将日期分解到单独的表中的主要考虑因素不应该是存储。这是一个关于数据模型的问题。正如 Gareth 指出的那样,内置日期的大小和外键的大小大致相同。
真正的问题是您是否需要有关无法从内置日期函数轻松获得的日期的其他信息。 MySQL 有一组丰富的日期函数,您可以在其中获取星期几、将日期格式化为字符串、提取组件等。此外,内置函数还可以处理比较、差异以及向日期添加“间隔”。
如果这些足够了,那么使用内置函数。另一方面,如果您有关于日期的“业务规则”,那么请考虑另一个表。以下是此类业务规则的示例:
- 一组特殊的日期,可能是假期。或者更糟糕的是,取决于国家/地区的假期。
- “季度”、“年份”、“一年中的一周”等的特殊业务定义。
- 需要支持多种日期格式以实现国际化目的。
- 有关日期类型的特殊规则,例如“工作日”与“周末”。
日期表只是处理这些问题的一种可能的解决方案。但如果您需要支持这些,那么拥有一个单独的日期表就有意义了。
关于mysql - 标准化日期(yy-mm-dd)还是坚持使用日期时间?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20289696/