MySQL Datefields：重複或計算？

Question

我們在10多年前使用了一張強加給我們的結構表。我們被允許添加列，但敦促不要更改現有的列。

某些欄目旨在表示日期，但放在不同的格式。除其他：

* CHAR(6): YYMMDD 
* CHAR(6): DDMMYY 
* CHAR(8): YYYYMMDD 
* CHAR(8): DDMMYYYY 
* 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

我一直在測試今天早上。我複製的表2次：

• 一次使用哪 變換VARCHAR字段插入每個查詢一個 DATE字段的圖，使用 STR_TO_DATE
• 一次添加一列並做一個UPDATE使用STR_TO_DATE

後來，我放開了很多不同的查詢 - 視圖執行慢一點，符合市場預期，但只有幾十毫秒。

因爲它確實需要額外7Mb來存儲額外的列（並且這對磁盤使用率和RAM使用有影響），並且我們的服務器具有CPU備用電源但不支持RAM/io，我正在學習朝向「在每個查詢上將CHAR轉換爲DATE」解決方案。

我不確定使用VIEW，存儲過程或只是將STR_TO_DATE放入每個要寫的查詢中 - 但這更像是一種「編碼最佳實踐」而非優化。