Discussion :

[Flore R.]

Bonjour,

Je m'entraîne pour un concours et je suis tombée sur cette question :




La formulation des jointures est la suivante :
SELECT *
FROM A JOIN B ON A.idA=B.idA
avec JOIN qui est adapté à la situation (INNER, FULL OUTER,...)

Est-ce que cette formulation implique que le JOIN se trouve dans le FROM, et donc que la réponse b. est vraie ?

On peut également utiliser WHERE pour réaliser des jointures, mais est-ce que selon vous, la question est formulée dans ce sens ?

D'instinct, j'aurais tendance à répondre a. et c.

Merci de toute aide que vous pourrez m'apporter.

Bien cordialement,

F.R.

[escartefigue]

C'est le genre de question piégeuse.
Effectivement, il n'y a pas de JOINsans FROM, de là à dire qu'on code (plutôt que programme) la jointure dans le FROM, je ne pense pas qu'on puisse le dire
Donc comme vous A et C
Bien évidemment, la jointure codée à l'ancienne dans le WHERE n'est pas recommandée et elle est incompatible avec les jointures externes.

[tatayo]

Bonjour,
Pour ma part j'interprète le choix B comme l'écriture qu'on voit passer régulièrement :

Code :

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

1
2
3
4
 
select x
from Table1,Table2
where table1.colx = table2.coly

Vu que la capture d'écran ressemble fort à un exercice, et que certains profs on du mal avec le JOIN...
Donc j'élimine le B

J'éliminerai le C car les critères de jointure doivent se trouver dans la clause JOIN. S'ils sont dans la clause WHERE, ça "implique" que la jointure est dans la clause FROM, donc que le choix B est valide.
Comme je l'ai écarté C, j'écarte de facto B.

D et E se passent de commentaire

Tatayo.

[escartefigue]

Bonjour,
Pour ma part j'interprète le choix B comme l'écriture qu'on voit passer régulièrement :

Code :

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

1
2
3
4
 
select x
from Table1,Table2
where table1.colx = table2.coly

Pour moi, cette syntaxe c'est plutôt la réponse C : le from fait le produit cartésien et les critères de jointures sont dans la clause WHERE
Mais bon, encore une fois, la question est piégeuse
Il serait plus intéressant de demander les différentes façon de coder les jointures, et là, le candidat pourrait explicitement les citer en donnant des exemples, sans tomber dans les pièges liés à l'interprétation de la question.

[Flore R.]

Bonjour,

Merci à tous pour vos réponses.

Ce n'est pas un exercice, c'est un extrait de l'annale 2016 du concours IESSA. Certaines de leurs questions sont piégeuses, comme le dit escartefigue.

La réponse c. doit être valide car on utilise WHERE pour certaines formulations de JOIN, par exemple quand on veut exclure l'intersection des deux tables : WHERE A.idA IS NULL.

[Waldar]

Bien évidemment, la jointure codée à l'ancienne dans le WHERE n'est pas recommandée et elle est incompatible avec les jointures externes.

Heureusement (pour nos seniors) c'est faux, le JOIN étant arrivé dans la norme SQL:92, les SGBDR savaient faire des jointures externes bien avant cela.

• Sur Oracle : where a.id = b.id(+)
• Sur Sybase (et SQL-Server 2000) : where a.id *= b.id

Pour la petite histoire Oracle converti toujours la syntaxe OUTER JOIN en WHERE (+) pour l'exécution de la requête en interne.

[escartefigue]

Je confirme, je crois pouvoir revendiquer le statut "d'ancien", plutôt que "sénior" qui signifie simplement "adulte" .

Mais sauf erreur de ma part, cette syntaxe est désormais obsolète sur la plupart des sgbd.

[Waldar]

Comme souvent c'est conservé pour la rétrocompatibilité des applications.

Code :

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

1
2
3
4
5
6
7
8
9
select t1.banner
     , t2.dummy
  from v$version t1
     , dual      t2
 where t2.dummy (+) = t1.banner;
 
BANNER                                                                  DUMMY
----------------------------------------------------------------------  -----
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

[vanagreg]

Oui, et d'ailleurs j'écris toujours mes requêtes comme ça sous Oracle

[Flore R.]

Bonjour,

Merci de venir apporter ces précisions. Donc vous confirmez que les réponses sont a. et c. en considérant la façon dont ils ont formulé la question ?

[escartefigue]

Stricto sensu, la jointure se fait avec l'opérateur JOIN.

WHERE fait une restriction sur le produit cartésien en cas de codage à l'ancienne FROM T1, T2, ..., Tn
Mais, l'optimiseur traduit le plus souvent (toujours ?) cette jointure à l'ancienne sous forme de vraie jointure pour n'avoir pas à faire le produit cartésien.

Donc, pour moi c'est réponse A sûre et réponse C compte tenu des explications qui précèdent.

[escartefigue]

Comme souvent c'est conservé pour la rétrocompatibilité des applications.

Code :

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

1
2
3
4
5
6
7
8
9
select t1.banner
     , t2.dummy
  from v$version t1
     , dual      t2
 where t2.dummy (+) = t1.banner;
 
BANNER                                                                  DUMMY
----------------------------------------------------------------------  -----
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Testé à l'instant sur Oracle 11g, SQL server 2017, Postgre 11, MySQL 5.7 et 8.0 et DB2 V12 for Z/OS avec les anciennes syntaxes
Seul oracle accepte l'ancienne version. Les quatre autres n'acceptent ni *= ni la syntaxe Oracle.

[Waldar]

Belles recherches !
Je savais que SQL-Server n'acceptait plus l'ancienne syntaxe depuis la refonte du moteur avec la version 2005, je pensais que DB2 serait un bon candidat pour la syntaxe vieillotte.

[escartefigue]

DB2 for Z/OS non, mais DB2 LUW oui, l'un et l'autre sont significativement différents

[vanagreg]

Je pense qu'Oracle accepte encore la vieille syntaxe car eux-mêmes doivent toujours avoir des vues système dont la requête utilise cette vieille syntaxe. Comme leur connerie de type LONG avec lequel tu ne peux rien faire, mais qui est toujours utilisé dans certaines vues système.