MySQL 日期字段 : duplicate or calculate?

Question

我们使用的表格具有 10 多年前强加给我们的结构。我们可以添加列，但强烈建议不要更改现有列。

某些列旨在表示日期，但采用不同的格式。其中:

 * CHAR(6): YYMMDD
 * CHAR(6): DDMMYY
 * CHAR(8): YYYYMMDD
 * CHAR(8): DDMMYYYY
 * DATE
 * DATETIME

由于我们现在想要使用高级日期函数进行一些更复杂的查询，我的经理建议使用 DATE 或 DATETIME 格式将这些问题列复制到适当的 FORMATTED_OLDCOLUMNNAME 列。

这是要走的路吗？ 我们不能在每次访问列时都使用 STR_TO_DATE 函数吗？为了避免每个查询都必须复制粘贴函数，我仍然可以使用 View 或存储过程，但复制数据以避免重新计算听起来是错误的。

我看到的解决方案(我想我更喜欢 2.2.1)

1. Physically duplicate columns
1.1 In the same table
1.1.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...)
1.1.2 Maintained by a trigger on each modification
1.2 In a separate table
1.2.1 Added by each script that does a modification (INSERT/UPDATE/REPLACE/...)
1.2.2 Maintained by a trigger on each modification
2. On-demand transformation
2.1 Each query has to perform the transformation
2.1.1 Using copy-paste in the source code
2.1.2 Using a library
2.1.3 Using a STORED PROCEDURE
2.2 A view performs the transformation 
2.2.1 A separate table replacing the entire table
2.2.2 A separate table just adding the date-fields for the primary keys

我说重新计算比存储更好是否正确？ View 会是一个好的解决方案吗？

Answer 1

我整个上午都在测试这个。我已经将表格复制了 2 次:

• 一次使用 View 将 VARCHAR 字段转换为每个查询的 DATE 字段，使用STR_TO_DATE
• 一次用于添加列并使用 STR_TO_DATE 进行更新

之后我释放了很多不同的查询 - View 执行速度有点慢，如预期的那样，但只有几十毫秒。

因为存储额外的列确实需要 7Mb 的额外空间，(这对磁盘使用和 RAM 使用有影响)，而且我们的服务器有空闲的 CPU 能力但没有 RAM/io，我倾向于“在每次查询时将 CHAR 转换为 DATE” 解决方案。

我不确定是使用 VIEW、存储过程还是只是将 STR_TO_DATE 放入我将要编写的每个查询中 - 但这更像是“编码最佳实践”而不是优化。