L’écriture des requêtes

mesure de la productivité était basée sur la façon de et certains langages permettaient de bien gagner sa vie parce que très verbeux, comme le fameux CoBOL…

Il est probable, tel un atavisme, que ce travers soit resté de nos jours. Pondre un programme de 2 000 lignes d’un code, même modernisé semble plus productif à bien des actuels tâcherons que d’optimiser une seule requête SQL sur la même période de temps et alors qu’elle remplit le même but ! « Je ne sais pas si mon patron apprécierait que je passe une journée sur la même requête » me disent certains, alors que j’interviens au prix fort pour rectifier une sauce qu’ils auraient pu réussir du premier coup à moindre frais…

Passé le cap de la culture, il y a aussi celui de la formation. Bien des développeurs sont capables d’écrire des algorithmes de gestion d’arbres sous forme récursive et avec un langage des plus moderne et ignorent encore que les jointures entre les tables s’effectuent dans une clause JOIN dont la syntaxe remonte à 1992 ! Pauvres universités, pauvres écoles d’ingénieurs où l’on concède à l’apprentissage des bases de données quelques maigres heures dans un cursus de quelques années… Bref, il faut bien le dire, à part quelques passionnés, peu d’informaticiens savent écrire de vraies requêtes. Alors de là à parler de techniques d’écriture…

Mais c’est pourtant ce que nous allons faire. Citons en trois : l’approche ensembliste, la résolution à petits pas et la technique d’ajout d’information. L’approche ensembliste consiste à considérer le problème sous l’angle des ensembles, c’est-à-dire avec les outils des mathématiques modernes que sont les diagrammes de Venn. Vous savez, les fameuses « patates » ! Cette technique consiste à penser ensemble et non ligne à ligne, à considérer le problème de manière globale et non comme à une série d’éléments ordonnés. Je prends souvent l’exemple introductif suivant : « une table est un sac de billes. Pouvez vous en extraire la dernière ? » La réponse fuse : impossible !

Mais si les billes ont été horodatées, alors la solution du problème saute aux yeux ! Considérez dès lors les ensembles et leurs opérations en regard des tables et des opérateurs de l’algèbre relationnel. Tiens… rien ne ressemble plus à une intersection qu’une jointure… Bref, commencez par dessiner les ensembles en jeu, faites les s’interpénétrer, s’exclure, se compléter et alors au beau milieu du graphe, la solution apparaîtra, bête, évidente… Mais il fallait y penser ! L’approche par petits pas consiste à partir d’une requête simple qui approche vaguement la solution puis de la compléter par petites touches.

Là où les choses s’enveniment, c’est lorsque le code de la requête grossit à cause de toutes les jointures, des différents prédicats des filtres WHERE et HAVING et de clauses plus barbares telles que les GROUP BY… Au fur et à mesure, il devient difficile d’y retrouver ses petits. Mais que cela ne tienne. Transformez cette première étape en un objet mille fois plus simple : une vue par exemple ! Dès lors vous pourrez à nouveau la farcir de quelques filtres et jointures supplémentaires, la placer en sous requête ou lui intimer d’en user…

C’est bien ce que vous faites en programmation objet ? Non ? En emboîtant vos objets dans d’autres et en nommant avec prétention le tout sous le nom générique de « classes » ! Qu’à cela ne tienne, utilisez les vues comme les expressions de table afin de parvenir au but. Si l’ensemble vous déplaît, alors réimbriquez la requête composant chaque vue dans celle qui abrite toute ces vues et peut être aurezvous la chance de trouver au final quelques simplifications. De plus, depuis l’apparition des expressions de tables, les fameuses CTE, l’imbrication des requêtes les unes dans les autres est encore facilité par la volatilité et la souplesse inhérente à cette construction. Usez-en, abusez-en !