Petit job d'été en plein boum de PHP3 et MySQL : après réalisation d'un outil de statistiques de trafic, je présente mon travail au chef du service informatique, accompagné de mon responsable "expert Web". En pleine réunion, mon responsable décide de regarder l'architecture de l'outil : tables MySQL, requêtes, code PHP, etc.
Je m'attendais à des critiques, mais pas à celle là : « Mais c'est n'importe quoi ! Tu as une table qui permet de lister les pages vues par IP, mais aucune table qui compte combien de fois chaque page est visitée !... ».
Je lui montre alors qu'avec la bonne requête il est possible d'avoir cette information à partir de cette même table, et que ceci permet d'éviter les informations en double et tous les problèmes associés à la duplication de données.
Depuis, je suis le « ouf » qui compte le nombre de lignes dans une table pour connaître le nombre d'enregistrements, plutôt que de le stocker dans une seconde table. PEBKAC.
J'ai alors passé quelques minutes à lui expliquer simplement le principe du join, il a refusé, disant que le programme perdrait en efficacité.
Il pense aussi que la requête SQL doit être le plus générale possible (et si possible SELECT * FROM TABLE) et puis faire un traitement (avec ruptures et tout, on se croirait encore à l'époque où je codais en COBOL) sur les lignes reçues pour en extraire les lignes dont on a besoin et les stocker dans un fichier (oui oui un fichier!).
Il a le rôle d'expert, et donc il faut toujours suivre ses idées... Dur!