Le 20ème siècle est si loin...
Sur les systèmes modernes, balayer une table volumineuse ne prend pas un temps infini. Cependant, s'il est possible de l'éviter, il est toujours dommage de lire plusieurs fois les mêmes données dans une requête afin de les joindre.
Nous allons considérer la table LANCERS contenant les performances des 54 géants du clan (idg est l'identifiant du géant, dtl la date du lancers et perf le résultat du lancer de cailloux en centimètres)
Oumpfor demande à son scribe Morgiono la moyenne glissante à 7 jours des performances maximales et minimales journalières pour chaque géant.
Margiono tente de l’écrire en partant d’un vieux bouquin SQL puis d’un livre plus récent :
La première requête globalement SQL-1992 utilise une auto-jointure et donne lieu à 2 balayages complets de la table LANCERS. La deuxième requête tire parti des possibilités analytiques offertes par la norme SQL:2003. Il est possible grâce aux clauses de fenêtrage de travailler de différentes façons (partionnement, tri) le jeu de résultats en mode "multiligne" APRÈS sa constitution et d'appliquer des fonctions analytiques. La deuxième requête neffectue quun seul balayage de LANCERS et surtout ne donne pas lieu à une auto-jointure. La première requête a pris environ 1s5 alors que la deuxième na pris que 0s4.
Si vous êtes (comme moi) un vieil habitué dOracle, vous ne connaissez peut-être pas la norme SQL:1992 et même la première requête et son "JOIN" peut vous sembler peu familière. Si vous utilisez des (+) quand vous voulez réaliser une jointure externe ou encore des start with...connect by quand vous voulez réaliser une requête hiérarchique alors vous êtes hors standard SQL. Je ne vous jette pas la pierre, changer les habitudes et donc prendre des risques nest pas facile lorsquon doit coder de nouvelles fonctionnalités avec de la pression au niveau des délais.
Je ne jette pas non plus la pierre à Oracle. Ce SGBD respecte les nouvelles normes mais conserve les syntaxes propriétaires pour compatiblité ascendante. Leurs requêtes hiérarchiques étaient par exemple disponibles depuis Oracle 2 au début des années 1980. Elles ont rendu bien des services mais écrire en 2016 du pseudo SQL des années 1980 cest dommage. Certaines versions propriétaires de PostgreSQL, comme celle dEDB, vous permettraient de garder ces (mauvaises) habitudes mais quitte à changer de SGBD autant les abandonner.
Esnuite pourquoi se limiter à 1992 ? Comme le rappelle "Use the index Luke", vous navez plus une station de travail sous Windows 3.1 mais sous Debian 10 ou Ubuntu 18.04 alors pourquoi se cantonner à SQL:1992 au niveau de votre SGBD ? Le passage à PostgreSQL peut être une bonne occasion de changer vos habitudes et de découvrir la richesse des dernières évolutions de la norme SQL.
PostgreSQL est particulièrement respectueux de la norme, la documentation indique clairement pour chaque syntaxe si vous utilisez quelque chose de "standard" ou une "extension de langage". En adoptant les nouveautés, vous rendrez votre code plus lisible et vous aurez peut-être en plus dexcellentes surprises au niveau des performances, comme dans le petit exemple présenté.