Question

我们正在使用一张十多年前强加给我们的结构的桌子。我们可以添加列，但敦促不要更改现有列。

某些列用于表示日期，但是以不同的格式放置。其中包括：

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

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

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

我看到的解决方案（我想我更喜欢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

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

Answer 1

我整个上午一直在测试。我已经两次复制了这张桌子：

一次用于使用哪个视图将VARCHAR字段转换为使用每个查询的DATE字段 STR_TO_DATE
一次用于添加列并使用STR_TO_DATE执行更新

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

因为我需要7Mb额外存储额外的列，（这对磁盘使用和RAM使用有影响），而且我们的服务器有CPU供电而不是RAM / io，我是倾向于“将CHAR转换为每个查询的DATE”解决方案。

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

MySQL Datefields：重复还是计算？

1 个答案: