Il y a quelques semaines, un peu agacé par une discussion où on m'expliquait, une fois encore, que pour obtenir de meilleures performances il fallait écrire une requête avec une syntaxe plutôt qu'une autre, j'ai écrit un article intitulé
NOT EXISTS, NOT IN ou OUTER JOIN, on s'en fout ! Comme Sisyphe avant moi, je sais qu'il faudra que je remonte ma pierre bientôt ; la mienne est faîtes d'idées reçues. La prochaine fois, elle sera juste un peu moins lourde.
L'intérêt des technologies Oracle, c'est que vous ne pouvez pas vraiment vous laisser aller ! Alors que j'avais préparé sur ce blog ma parade, j'ai pris un raccourci. Et bien, c'est quand vous prêtez le flan qu'on vous rentre dedans gentillement.
Donc c'est vrai ! Je me laisse aller à prendre des raccourcis. Pire : je le fais exprès ! Il faut dire, à ma décharge, que le contexte du moment n'était pas exactement à discuter des subtilités de l'optimiseur avec des esprits brillants mais plutôt l'inverse (pourvu qu'ils ne se reconnaissent pas ;-D). Enfin, c'est un mal pour un bien puisque, j'imagine en écho à mon article et sur
son blog, Ahmed AANGOUR a écrit
SEMI-JOINS : IN vs EXISTS. Dans cet article, il explore avec intelligence un autre cas d'idée reçue et met le doigt sur l'époque de ces changements, c'est à dire la version 8i, grâce au paramètre
optimizer_features_enable. Il a un esprit affuté, de la rigueur, des références saines et il ne se laisse pas encore aller comme moi à des concessions. Il doit être jeune ; je ne saurais trop vous conseiller de vous abonner à son blog, les bonnes ressources en français ne sont pas si répandues. Je lui souhaite de continuer à être exigeant.
Mais il m'appartient maintenant d'expliquer mon raccourci ; en quoi les clauses
NOT IN et
NOT EXISTS sont en réalité différentes et l'astuce que j'ai utilisée sans le dire dans mon article pour les rendre identiques...
