MySQL Datefields: dupliquer ou calculer?

Question

Nous utilisons une table dont la structure nous a été imposée il y a plus de 10 ans. Nous sommes autorisés à ajouter des colonnes, mais invité à ne pas modifier les colonnes existantes.

Certaines colonnes sont censées représenter des dates, mais sont placées dans un format différent. Entre autres:

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

Depuis que nous voudrions maintenant faire des requêtes plus complexes, en utilisant les fonctions de date avancées, mon manager a proposé de dupliquer les colonnes de problème à une colonne de FORMATTED_OLDCOLUMNNAME appropriée en utilisant un format de date ou DATETIME.

Est-ce la voie à suivre? Ne pourrions-nous pas simplement utiliser la fonction STR_TO_DATE chaque fois que nous avons accédé aux colonnes? Pour éviter que chaque requête n'ait à copier-coller la fonction, je pourrais toujours travailler avec une vue ou une procédure stockée, mais dupliquer des données pour éviter que le recalcul ne sonne mal.

Solutions Je vois (je crois que je préfère 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 

Ai-je raison de dire qu'il est mieux que de stocker recalcule? Et est-ce qu'une afficher serait une bonne solution?

Answer 1

J'ai été testant toute la matinée. J'ai dupliqué le tableau 2 fois:

• une fois pour utiliser une vue qui transforme le champ VARCHAR dans un champ DATE sur chaque requête, en utilisant STR_TO_DATE une fois
• pour ajouter une colonne et faire un UPDATE en utilisant STR_TO_DATE

Ensuite je laisse perdre beaucoup de requêtes différentes - la vue effectue un peu plus lent, comme prévu, mais seulement quelques dizaines de millisecondes. Comme il me faut 7Mo de plus pour stocker la colonne supplémentaire, (et cela a des implications sur l'utilisation du disque et l'utilisation de la RAM), et notre serveur a de la puissance CPU mais pas de RAM/io, vers le "transformer le CHAR en DATE sur chaque requête" solution. Je ne suis pas sûr d'utiliser une VIEW, une procédure stockée ou simplement de mettre le STR_TO_DATE dans chaque requête que j'écrirai - mais c'est plus une «meilleure pratique de codage» qu'une optimisation.