Discussion :

[joKED]

Bonjour,

J'utilise régulièrement l'opérateur EXISTS avec sous requête lorsque je veux vérifier qu'une donnée est bien présente dans une table.

Toutefois, j'ai vu plusieurs exemples d'utilisation de cet opérateur dans divers tutos cet opérateur, et je reste circonspect d'un point de vue performance sur la forme des sous requêtes utilisées.

Voici plusieurs exemples :
Exemple 1 avec SELECT * :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE EXISTS (SELECT * FROM MATABLE WHERE ...)

Exemple 2 avec SELECT MON_FIELD

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE EXISTS (SELECT MON_FIELD FROM MATABLE WHERE ...)

Dans l'exemple 1, l'opérateur EXISTS reçoit une subquery qui renvoie tous les champs de la table. Je suppose qu'il s'agit d'une mauvaise pratique. Quel intérêt de ramener tous les champs pour simplement vérifier une existence ?

Dans l'exemple 2, l'opérateur EXISTS reçoit une subquery qui renvoie un seul champ de la table. C'est déjà mieux AMHA. Toutefois, doit on privilégier le champs correspondant à la PK de la table ? Ou tout autre champs peut il faire l'affaire ? Quelle est la bonne pratique à ce niveau ?

Vous remerciant par avance pour vos lumières.

PS : Ceci n'est pas un débat sur l'opportunité d'utiliser EXISTS vs JOIN vs IN . Juste une question pour connaitre la meilleure manière de procéder lorsque l'on utilise EXISTS.

[escartefigue]

Bonjour,

Avec (NOT) EXISTS, la requête correlée ne transporte aucune donnée, seulement un booléen vrai/faux

Du coup il n'y a aucune différence entre l'une et l'autre requête en termes de performances

Cela étant, je préfère utiliser une constante, par exemple SELECT 1, pour bien mettre en évidence ce fonctionnement et aussi ne pas inciter les débutants à coder des SELECT *qui dans tout autre contexte sont à proscrire

[joKED]

Bonjour,

Avec (NOT) EXISTS, la requête correlée ne transporte aucune donnée, seulement un booléen vrai/faux

Ah, voilà le morceau d'information pertinent qui me manquait.

Bien noté aussi pour l'idée d'utiliser une constante, c'est effectivement une très bonne idée.

Merci beaucoup, ça répond parfaitement à mes interrogations.

[soazig]

Coucou,
Personnellement je prefere utiliser Select null dans les exists comme ça en lisant on voit bien qu'on se moque du contenu.
Cordialement
Soazig

[escartefigue]

Bonjour Soazig

Pourquoi pas, mais comme je l'ai indiqué récemment dans un autre sujet, SELECT NULL n'est pas applicable sur tous les SGBD alors que SELECT constante l'est

[SQLpro]

Dans les cours que je donne je met souvent la forme suivante pour ce type de requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE EXISTS (SELECT 1/0 FROM MATABLE WHERE ...)

Cela me permet de voir si le serveur SQL fait bien son boulot… Sur SQL Server ce 1/0 ne provoque aucune erreur, tout simplement parce que le contenu du SELECT n'est jamais lu, ce qui est le principe même de ce type de requête….
Et moins le serveur SQL fait de chose, plus ça va vite !

A +

[joKED]

Sur SQL Server ce 1/0 ne provoque aucune erreur, tout simplement parce que le contenu du SELECT n'est jamais lu, ce qui est le principe même de ce type de requête….

C'est intéressant ça.
Si je mets n'importe quelle expression syntaxiquement valide, ça fonctionne (genre 3x2 ou 40-5 ou 0 ou 1/0 ...)

Mais par contre, si je mets un nom de colonne qui n'existe pas dans la table, j'ai une belle erreur m'indiquant que la colonne n'existe pas.

Donc, le contenu du SELECT n'est jamais lu, mais si quand même un peu en fait . Enfin, il n'est pas lu, mais analysé alors ? (je dois pas avoir les bons termes je pense).

PS : La question initiale est bien résolue, c'est juste pour ma culture personnelle.

[StringBuilder]

Je ne sais plus où j'ai lu que le "mieux" était d'utiliser "*" justement en raison de l'analyse des noms de colonne indiquées dans la sous-requête.
=> Avec *, le SGBD n'a pas besoin d'aller vérifier que le nom des colonnes existes ni que l'expression est une constante/expression valide.


Auparavant, j'utilisais "null", mais les noobs qui passent derrière comprennent jamais et pensent qu'on vérifie qu'il n'y a rien, ou je ne sais quoi.
Idem avec "1", y'en a qui vont encore croire qu'on cherche à compter les lignes, ou qu'on cherche à vérifier qu'il y en a une et une seule (c'est incroyable comme certains sont pas tous seuls dans leur tête).

Le * a l'avantage que si tu dis aux noobs "tu écris une requête avec une * t'es viré", quand le gars se pointe tout fier en disant "oué ben vire-toi parce que t'as mis une étoile", ça donne l'occasion de lui expliquer comment fonctionne le EXISTS, alors que si tu lui expliques avant, il oubliera/n'écoutera pas.


En revanche, le * est bien embêtant sous SQL Server, car tu ne peux pas compiler une procédure stockée "with schemabinding"... C'est vraiment dommage car comme l'a si bien dit SQLPro, OSEF ce qu'il y a dans le sous-SELECT... mais le compilateur n'est pas de cet avis.

Du coup je crois que pour cette raison je vais me mettre aussi à utiliser 1/0... Comme ça, ça choquera toujours autant les noobs, sans pour autant faire râler le compilateur

[Waldar]

Si je mets n'importe quelle expression syntaxiquement valide, ça fonctionne (genre 3x2 ou 40-5 ou 0 ou 1/0 ...)
Mais par contre, si je mets un nom de colonne qui n'existe pas dans la table, j'ai une belle erreur m'indiquant que la colonne n'existe pas.

Il y a plusieurs étapes derrière l'exécution d'une requête, entre autre le parsing syntaxique, le parsing des objets puis l'interprétation.

[SQLpro]

Je ne sais plus où j'ai lu que le "mieux" était d'utiliser "*"

Oui et non, ça dépend du SGBDR… La plupart analysent quand même les colonnes et faisant donc des requêtes de métadonnées pour rien…. Ce fut le cas de SQL Server dans les versions antérieurs à 2008 je crois.

A +