Discussion :

[Rei Ichido]

Ben moi qui m'attendait à ne pas avoir de réponse, ou une petite règle générale du genre "celle que tous tes collègues arrivent à relire", me voilà bien avancé

À la limite, à part les requêtes horriblement mal pensées, si je devais citer une règle à appliquer avant toute considération de perf, ça serait bien cette dernière : une requête lisible facilement, y compris par le petit stagiaire qui devra un jour modifier la requête pour un changement fonctionnel.
Si ensuite il y a des problèmes de perf, zou, on sort l'artillerie.

[Waldar]

Je ne suis pas du tout d'accord avec la proposition de Rei Ichido, ce serait un sacré nivellement par le bas.


Pour apporter ma pierre à l'édifice, je dirai qu'il faut surtout commencer par écrire la requête qui répond au besoin, vérifier qu'elle n'est pas délirante en terme de temps de réponse et si besoin chercher à l'améliorer.

Rappelons le besoin :

Je dois rechercher tous les contrats pour lesquels il existe au moins un poste avec DATAPP vide (égale à ' ').

Je ne vois qu'une seule et unique interprétation possible en SQL, et comme par magie c'est la plus rapide !

La deuxième requête SQL serait l'interprétation de :
Je recherche tous les contrats parmi les contrats des postes avec un DATAPP vide.

La troisième requête SQL :
Parmi tous les contrats des postes ayant un DATAPP vide, je dois afficher les premiers une seule fois.

Dans ce cas de figure, j'écris naturellement la première requête, je l'exécute elle répond vite, travail terminé.
Pas besoin de regarder le plan d'exécution.
Si la requête était plus complexe avec plus de tables en jeu, j'y jetterai certainement un œil toutefois.

[skuatamad]

Non seulement le temps de réponse est raisonnable, mais en plus, l'optimisation du plan d'exécution ne se pose plus : les critères appliqués sur la vue sont dynamiques, et j'ai pu constater que le plan d'exécution était parfois très différent (dans certains cas, on commence par un full scan dans la table CNP -assez lent- et dans d'autres cas, on commence par un scan unique index dans CNT, ce qui est on ne peut plus rapide).

Attention à ce que les tests soient fait dans les même conditions que l'execution de l'appli.
Si la vue est filtrée par des valeurs en dur (comme dans l'exemple du 1er post), modifier ces valeurs signifie pour oracle nouvelle requête donc nouveau plan.
Donc en fonction de la répartition de données oracle peut choisir entre un full scan ou un accès par index.

Par contre en fonction du contexte, notemment en OLTP il est indispensable d'utiliser des binds variables afin de réutiliser des plans valables pour de nombreuses valeurs différentes.
Un côté négatif des bind variables est (en 10G -) le phénomène de bind variable peeking, le plan est déterminer avec la 1ere variable passée puis tant que ce plan est en cache toutes les executions de la requête utiliseront le même plan.

Je trouve ce lien (le followup) intéressant pour comprendre le fonctionnement des histogramms et leur impacte sur le choix des plans.
Interpreting Histogram Information
Et également HISTOGRAMS - MYTHS AND FACTS sur le site de Wolfgang Breitling

une requête lisible facilement, y compris par le petit stagiaire qui devra un jour modifier la requête pour un changement fonctionnel.

Pour moi c'est la requête qui répond à la question, je ne trouve pas forcément très agréable d'avoir à lire 200 lignes de codes procédurals parceque bon un stagiaire non formé au SQL pourrait être obligé d'apprendre de nouvelles techniques... Et là j'ai même pas parlé de perfs !

[mnitu]

...
Quant au saint Graal, il s'impose d'évidence dès lors que tu dis qu'il faut écrire la (bonne) requête de manière proactive.
Le petit bémol, c'est que tu oublies juste de proposer une solution !

Avez-vous remarqués que les trois requêtes proposées ne donnent pas le même résultat et donc ne sont pas équivalentes ?

[Rei Ichido]

Je ne suis pas du tout d'accord avec la proposition de Rei Ichido, ce serait un sacré nivellement par le bas.


Pour apporter ma pierre à l'édifice, je dirai qu'il faut surtout commencer par écrire la requête qui répond au besoin, vérifier qu'elle n'est pas délirante en terme de temps de réponse et si besoin chercher à l'améliorer.

On parle bien ici de choisir entre des requêtes qui donnent le même résultat et dont les performances ne sont pas a priori tellement différentes. J'écris bien "a priori", car au final seul les tests permettront de trancher.
Donc si j'ai le choix entre faire une requête totalement obscure, et une qui est plutôt intuitive, et que celle qui est intuitive passe correctement, oui je préfère cette deuxième. Si jamais il y a un problème de performance, et bien je pourrais envisager la requête obscure (ou encore une autre, en creusant plus, éventuellement en hintant).

Mon métier, ce n'est pas de me faire plaisir en faisant des requêtes de l'espace pour le plaisir de gagner 1% de temps de réponse ; c'est de fournir à mon client quelque chose de fonctionnel, et si possible facilement maintenable.

[mnitu]

C’est quoi « obscure » et quoi « intuitive » ? Qui décide que c’est « intuitive » votre petit stagiaire de service ?

[Rei Ichido]

Obscur/intuitif, c'est évidemment moi qui tranche (puisqu'on parle de comparer des requêtes) selon ce que j'estime le plus facile à lire. Évidemment, charge à moi de commenter ensuite pour que ça soit le plus compréhensible possible.

[Waldar]

Pour résumer, c'est votre niveau en SQL qui définit ce qui est maintenable ou pas !

Le jour où vous remplacez quelqu'un qui était meilleur que vous en SQL vous allez donc tout réécrire ?

[Rei Ichido]

On s'égare un peu (et pas seulement de l'Est).

Mais si je remplace quelqu'un dont le niveau est meilleur que le mien, et que je suis amené à modifier une requête, que cette modification peut se faire de deux façon différentes, dont l'une me semble plus compréhensible sans pour autant pourrir les perfs (point de départ de la discussion), alors je vais choisir la modification la plus claire.

Edit :

Pour résumer, c'est votre niveau en SQL qui définit ce qui est maintenable ou pas !

Non, mais ne me considérant pas comme spécialement bon en SQL, si j'ai le choix entre deux façons de faire dont l'une me semble complexe, alors je me dis (peut-être à tort, certes) que mon remplaçant aura bien des chances de mettre beaucoup de temps à comprendre/modifier/débugger. Donc je vais préférer opter pour une requête plus claire, ou une procédure plus découpée.

[mnitu]

En ce qui concerne la question de départ la réponse est : utiliser EXISTS ou IN comme cela vous plait.

En fait actuellement l’optimiseur génère le même plan pour les deux.

Pour ceux qui aiment ANY voir l’obscur SOME prenez en compte le fait que SOME est un synonyme du ANY et que ANY et transcrit en interne via EXISTS.

Pour ceux qui pensent que dans le cas d’EXIST la sous-requête est exécutée pour chaque enregistrement de la table directrice un bref regard sur le plan d’exécution met bien évidence l’opération de semi-jointure utilisée : nested loop semi, hash join semi ou sort merge join semi. La présence d’une opération de semi-jointure indique précisément que l’optimiseur fait une jointure « un peu spéciale » entre la table directrice et l’autre table (ou index) qui s’arrêt de que la première ligne qui corresponde est trouvée.