Discussion :

[Bandalf]

Bonsoir, je me pose une question par pure curiosité sur laquelle je réfléchis depuis plusieurs heures et j'aimerais des avis extérieurs :

Existe t'il des sous-requêtes formulées de telle sorte qu'il soit absolument obligatoire d'utiliser exists ou not exists ?

je m'explique : cette réflexion fait suite à un exercice vu en cours aujourd'hui dans lequel il était demandé de trouver la requête sql pour une situation donnée très tordue. La solution la plus complexe à comprendre mais la plus simple a appliquer passait par l'utilisation de exists et not exists mais nous avons vu ensuite qu'il était possible d'apporter une solution sans, via une suite de sous-requêtes un peu tordues.

Ainsi, on se demande s'il existe des requêtes qui ne soit vraiment pas possible de résoudre sans utiliser exists et not exists ! Des idées ?

J'espère avoir été clair .

[sevyc64]

c'est tout à fait probable que ça existe mais je n'ai pas d'exemple à donner.

Par contre, une clause EXISTS avec une sous-requête est à éviter, dans la mesure du possible, car très gourmande en ressources. En effet, la sous-requête est exécutée pour chacun des enregistrements retournés par la requête principale avant application des clauses du where, surtout notamment si dans le where de la sous-requête, tu fais intervenir la valeur d'un champ de la requête principale.

[Bandalf]

D'accord merci bien !! Je vais continuer à chercher un peu si j'arrive à trouver une situation qui colle !

[SQLpro]

Non, le EXISTS / NOT EXISTS peut toujours être remplacé par autre chose. Il n'est pas indispensable. Parmi les remplacement :

• JOINTURE (pas pour tous les cas)
• IN / NOT IN (possible pour tous les les cas)
• SOME, ANY ou ALL (possible dans la plupart des cas
• CTE

Bref, on peut TOUJOURS remplacer l'opérateur EXISTS, mais on ne peut pas se passer de sous requêtes.

A +

[julien94320]

+1 avec SQL PRO

Il existe plusieurs manière d'écrire une même requête nous somme dans un langage ensembliste avec un algèbre relationnel si le model est bien conçu et que l'algébriseur traduit bien la requête le plan a de forte chance d'être le même et donc les performances risquent d'être les mêmes.

SQL PRO a bien cité les autres manière et il y a tout un tas de possibilités qui existent encore...

Seul différence la maintenance pour les personnes venant lire et donc comprendre la requête.

A+

[SQLpro]

Par contre, une clause EXISTS avec une sous-requête est à éviter, dans la mesure du possible, car très gourmande en ressources. En effet, la sous-requête est exécutée pour chacun des enregistrements retournés par la requête principale avant application des clauses du where, surtout notamment si dans le where de la sous-requête, tu fais intervenir la valeur d'un champ de la requête principale.

Excuse moi de le dire franchement mais c'est des conneries !
En effet dans bien des cas le EXISTS va être plus rapide que n'importe quelle autre expression. Simplement par ce que :
1) la sous requête EXISTS ne renvoie rien, contrairement à la sous requête avec IN qui construit un dataset puis fait une jointure
2) dès la première ligne atteinte satisfaisant la condition, l'opérateur EXISTS arrête son travail, car on n'exige pas de lui qu'il aille vérifier toutes les ligne qualifiée, une seule suffit

Donc, dans la plupart des cas il est BEAUCOUP plus rapide ! Sauf si tu es sur un pseudo SGBD peu relationnel mal branlé du genre MySQmerde !

A +

[julien94320]

ET comme tu l'as dit ... Si le SGBD est bien gaulé, si la requête demande la même chose elle sera interprété de la même manière par l'agébriseur et donc on aura les mêmes perfs ...

Donc NOT EXISTS sera plus rapide dans certains cas mais la plupart du temps on aura les mêmes perf et il ne sera dans tous les cas pas moins rapide ...

[sevyc64]

Excuse moi de le dire franchement mais c'est des conneries !

C'est pourtant ce que j'ai pu constater assez régulièrement, enfin, les fois ou il a fallu se pencher sur des problèmes de performance de certaines requêtes. Et quand on fait un profiling et que l'on voit des milliers/millions de requêtes identiques passer pour un seul jeu de résultat, et que ces requêtes correspondent à la sous-requête du exists, on comprend (croit comprendre, à tord, donc) d'où vient le problème.

Mais peut-être que ce n'est du qu'au fait, effectivement, que les requêtes sont mal écrites, et pas forcément donc du à l'utilisation de Exists.


Là ou je vous rejoins, mais sans avoir votre expertise (c'est pour cela que je n'ai pas affirmé dans ma première réponse), je n'ai, pour le moment, pas encore rencontrer de syntaxe avec un EXISTS qui ne pouvait être réécrite autrement, même si parfois il faut bien se tordre les méninges.

[SQLpro]

...enfin, les fois ou il a fallu se pencher sur des problèmes de performance de certaines requêtes...

ben oui, mais comme tu te penches sur les mauvaises perfs et pas les bonnes, tu trouve que tout va mal.!!!!

Il faut aussi regarder les requêtes qui vont bien !!!!!!

D’où ton erreur d’appréciation

A +