IF EXISTS select 1 et IF EXIST SELECT null

bonjour

Sur plusieurs type du requêtes utilisé dans mon programme j'ai besoin de tester l’existante des éléments a travers la commande IF EXISTSs

pour cela je cherche la différence entre ces deux partie de transact

Code:

---

IF EXISTS(Select null from table)

---

et

Code:

---

IF EXISTS(Select 1 from table)

---

quel la différence entre les deux ?et Quel est le plus performant entre les deux

merci pour vos aide et explication

Bonjour,

Il n'y a aucune différence entre les deux (et donc aucune différence de performance)

par nature, EXISTS teste l’existence de ligne, le contenu du SELECT n'importe donc pas.

Citation:

---

Envoyé par aieeeuuuuu

Bonjour,

Il n'y a aucune différence entre les deux (et donc aucune différence de performance)

par nature, EXISTS teste l’existence de ligne, le contenu du SELECT n'importe donc pas.

---

Et même SELECT * est parfait dans ce cas !!!!!!!
Y compris s'il y a un groupage parce qu'il se fout totalement du contenu de la clause SELECT !!!!!!!

A +

Un bémol cependant avec le * : si on crée un objet lié au schéma, SQL Server est un peu con dans sa tête, et refuse le * (alors qu'il n'a aucune raison de le prendre en compte dans ce cas précis, pas plus que dans un COUNT(*) d'ailleurs) mais c'est comme ça, le gars qui a écrit le compilateur T-SQL était certainement une grosse faignasse et n'a fait le boulot qu'à moitié (testé avec SQL Server 2014 Express)

(mode troll des plages qui revient avec la serviette autour de la taille).

Citation:

---

Envoyé par StringBuilder

Un bémol cependant avec le * : si on crée un objet lié au schéma, SQL Server est un peu con dans sa tête, et refuse le * (alors qu'il n'a aucune raison de le prendre en compte dans ce cas précis, pas plus que dans un COUNT(*) d'ailleurs) mais c'est comme ça, le gars qui a écrit le compilateur T-SQL était certainement une grosse faignasse et n'a fait le boulot qu'à moitié (testé avec SQL Server 2014 Express)

(mode troll des plages qui revient avec la serviette autour de la taille).

---

Désolé de te contredire, mais il était parfaitement logique et respectueux de la norme !
En effet, la norme SQL précise qu'en cas d'utilisation de * dans le SELECT pour une vue, la vue doit être stable et en particulier ne pas avoir deux colonnes portant le même nom...
Or en laissant * dans le SELECT on peut se retrouver à terme avec deux fois le même nom auquel cas la vue ne marche plus ce qui serait contradictoire avec la stabilité attendue par le SCHEMABINDING !

A +

Citation:

---

Envoyé par SQLpro

Or en laissant * dans le SELECT on peut se retrouver à terme avec deux fois le même nom auquel cas la vue ne marche plus ce qui serait contradictoire avec la stabilité attendue par le SCHEMABINDING !

---

Justement, pas dans le cas où le * se situe dans un "EXISTS" au sein de la vue :

Code:

---

1 2 3 4 5 6 7 8 9 10

create view v_a_existant_dans_b (id, nom) with schemabinding select a.id, a.nom from tableA a where exists ( select * from tableB b where b.id = a.id )

---

=> Ne compilera pas si on lie la vue au schéma.

Pourtant :

Code:

---

1 2 3 4 5 6 7 8 9 10

create view v_a_existant_dans_b (id, nom) with schemabinding select a.id, a.nom from tableA a where exists ( select 'j''aime les nouilles pas toi ?' from tableB b where b.id = a.id )

---

Compile tout à fait.

Tout autant que :

Code:

---

1 2 3 4 5 6 7 8 9 10

create view v_a_existant_dans_b (id, nom) with schemabinding select a.id, a.nom from tableA a where exists ( select b.id, b.id, b.nom, b.nom from tableB b where b.id = a.id )

---

=> Alors qu'il y a des colonnes de même nom dans le sous-select

En fait, quel que soit le nombre de colonnes dans B (qui ne peuvent de toute façon pas être synonymes), le lien avec le schéma ne peut en aucun cas être remis en question en cas d'évolution de la table "tableB".
J'estime que dans ce cas, même si ça peut te paraître moche, le "*" pourrait parfaitement être toléré avec un SCHEMABINDING, car quelles que soient les évolutions de la structures des objets impliqués dans la vue, en aucun cas le "*" ne peut remettre en question la stabilité de la vue.

Faites comme moi, proscrivez le select * que ce soit dans un test d'existence ou ailleurs c'est tellement mieux ainsi :)

Citation:

---

Envoyé par StringBuilder

le gars qui a écrit le compilateur T-SQL était certainement une grosse faignasse et n'a fait le boulot qu'à moitié

---

Autant je comprends que le test d'existence dans la définition d'une vue liée au schéma par une étoile vous déçoive, autant votre remarque est assez démesurée :mouarf:

Je doute qu'écrire un compilateur soit simple, tout autant du fait qu'il n'y ait qu'une seule personne qui ait participé à l'implémentation ;)
Il suffit pour cela de penser aux cas à vérifier pour s'assurer que la vue peut être liée au schéma.
Dans l'exemple que vous donnez avec la constante de type chaîne, effectivement c'est choquant, mais du point de vue du compilateur, c'est une constante (au sens invariable du terme :D).

@++ ;)

D'où ma phrase :

Citation:

---

(mode troll des plages qui revient avec la serviette autour de la taille).

---

Evidement, j'imagine bien que c'est pas si simple, d'autant qu'il n'y a aucun intérêt fonctionnel à faire une exception du * dans un EXISTS.