Il peut sembler naturel dutiliser SQL pour travailler sur les données stockées dans un SGBDR. Pourtant, en pratique, ce nest pas aussi simple et certains obstacles peuvent se présenter.
La complexité grandissante dun traitement amène parfois le développeur à tenter de découper une requête SQL, voire de réaliser certaines tâches avec un autre langage de programmation.
Abandonner SQL nest pas toujours la bonne approche, ce langage est très souvent loutil à privilégier pour obtenir les meilleurs performances avec un SGBDR.
Débusquer le Minotaure tapi dans un programme labyrinthe
Une collègue ma posé une question concernant loptimisation dune fonctionnalité en cours de développement. Cest une démarche intéressante, il est préférable de ne pas avoir à intervenir alors quil est déjà trop tard et que la lenteur est constatée en production.
En extrapolant à partir des premiers résultats obtenus en test, la durée du traitement en production aurait été dune centaines dheures. Le traitement devant pouvoir sexécuter quotidiennement, la situation aurait été inacceptable.
Le traitement consiste à produire depuis la base de données dune application transactionnelle un fichier au format défini et imposé, destiné à alimenter une application décisionnelle.
Le programme est développé avec un AGL produisant au final du C. Avec les explications de ma collègue, jai pu déterminer que le principe général du programme était le suivant :
Informations sur les différentes étapes :
Un fil dAriane : SQL
Que pouvons-nous faire en SQL au lieu de le faire au niveau du programme en C ?
La requête REQUETE_B consistant à utiliser des variables obtenues depuis la requête REQUETE_A était en fait une JOINTURE effectuée au niveau du programme. REQUETE_A et REQUETE_B peuvent donc être remplacées par une requête REQUETE_AB effectuant la jointure SQL des résultats entre REQUETE_A et REQUETE_B.
Larrondi effectué par le programme C peut être réalisé en SQL
Pivoter les résultats (regrouper les données de plusieurs lignes et les afficher dans différentes colonnes sur une seule ligne) peut être réalisé en SQL, voir cet article. La solution retenue est celle basée sur CASE car le programme doit être compatible avec Oracle et PostgreSQL, la table de travail devient inutile
Le regroupement qui était effectué par la requête REQUETE_C est ajouté à REQUETE_AB qui devient REQUETE_ABC (GROUP BY)
Cela donne au final UNE requête et le nouveau principe du programme est le suivant :
Conclusion
Optimiser a posteriori en observant ce qui se passe sur la base est possible mais mieux vaut prévenir que guérir. Dans lexemple que jai donné, la requête B serait bien sûr apparue dans une analyse effectuée avec le traqueur mais même cet outil naurait pas immédiatement donné la logique complète du traitement.
.
Le réflexe du DBA peut être de tenter immédiatement doptimiser la requête, dajouter un index etc. Ce nest pas la meilleure méthode et il est souvent préférable de comprendre globalement ce que doit faire un traitement avant de se lancer dans une optimisation. La principale optimisation consistait en fait ici à réaliser la jointure et le pivot en SQL et non au niveau du programme C.
Les optimisations les plus importantes sont accomplies pendant la phase de développement. Cest donc le développeur qui peut les réaliser en utilisant le bon outil pour la bonne tâche. Et pour traiter des données stockées dans un SGBDR, difficile de faire mieux que SQL.