[Sondage] Jointures dans WHERE ou avec JOIN ?

**Rei Angelus** · 11/08/2006, 10h56

Suite au post :
http://www.developpez.net/forums/sho...d.php?t=195327

Je m'interroge sur le gestion des jointures dans le monde SQL. Il semblerait en effet que pas mal de monde soit rester aux jointures dans la clause WHERE. Quelles en sont les raisons ?

**Rei Angelus** · 11/08/2006, 11h03

Pour ma part, j'ai appris à faire mes jointures dans le WHERE.

J'ai voulu me mettre à niveau récemment mais mon SGBD ne gère pas la syntaxe JOIN

.

**Cybher** · 11/08/2006, 11h08

moi je fais les jointures avec join.
j'ai appris par moi meme. au départ je trouvais plus facile de le faire dans le WHERE mais à force d'entendre que ce n'etait pas normalisé je me suis mis tres rapidement au JOIN

**al1_24** · 11/08/2006, 11h16

J'ai appris avec JOIN et, quand j'ai dû travailler sur Oracle, j'écrivais mes requêtes avec le JOIN en commentaire que je convertissais en WHERE dans le code...

**Fleur-Anne.Blain** · 11/08/2006, 13h50

Bonjour,

Pour ma part, durant mon cursus scolaire, l'on m'a uniquement appris ( et donc je ne connaissais pas les jointures avec JOIN) à faire mes jointures dans la clause WHERE. Ce n'est qu'en entreprise où j'ai peu à peu modifier cette habitude , et donc utilisé JOIN.

@++

**Rei Angelus** · 11/08/2006, 14h00

Envoyé par trinityDev

Bonjour,

Pour ma part, durant mon cursus scolaire, l'on m'a uniquement appris ( et donc je ne connaissais pas les jointures avec JOIN) à faire mes jointures dans la clause WHERE. Ce n'est qu'en entreprise où j'ai peu à peu modifier cette habitude , et donc utilisé JOIN.

Idem. En école, on ne nous a pas parlé de JOIN, j'ai découvert cette syntaxe sur ce forum.

Il semblerait que la formation SQL dispensée au niveau scolaire ne soit pas tout à fait à jour. Ca craint !

**Fleur-Anne.Blain** · 11/08/2006, 14h07

Après 3 mois intensif à faire du SQL et PL/SQL ( et a galerer sur des problèmes de dates

), je confirme que l'enseignement n'est plus à jour, et pourtant il me reste deux ans...à apprendre les mêmes choses en SQL...

**Luc Orient** · 12/08/2006, 08h18

Je crois qu'on est tous d'accord pour dire que l'écriture d'une jointure avec la clause JOIN est supérieure en lisibilité et en clarté à celle avec la clause WHERE ...
Par contre, il faut bien aussi constater qu'on trouve encore beaucoup de requêtes de jointure écrites avec la clause WHERE et ceci pour tout un tas de raisons ...
Pour moi il est clair qu'il faut donc connaître et maîtriser les deux syntaxes.
J'ajouterais que pour une jointure interne, la sémantique et les accès sont strictements identiques. Donc à mon avis, cette question est un point de détail et ne mérite vraiment pas qu'on en fasse tout un plat ...
Encore une fois je ne parle que des jointures internes ... les autres types de jointure ne peuvent s'exprimer que par la clause JOIN et là il n'y a plus matière à débat ...

**Rei Angelus** · 16/08/2006, 13h16

Envoyé par Luc Orient

Pour moi il est clair qu'il faut donc connaître et maîtriser les deux syntaxes.

Entièrement d'accord. Le problème c'est que l'apprentissage et la pratique ne laissent pas à la place aux 2 syntaxes.

Par exemple, sur le forum j'ai tendance à laisser tomber les problèmes de requêtes avec JOIN étant donné que le temps que je passe du mode WHERE au mode JOIN

est apparu.

Xo · 16/08/2006, 13h23

Je me permets un petit rappel pour ceux qui ne seraient pas sûrs de la conduite à adopter, suite à la lecture de ce sondage :
- Cours sur les jointures : Les jointures, ou comment interroger plusieurs tables
- En particulier : 1.2. Différents type de jointures (naturelles, équi, non equi, auto, externes, hétérogènes, croisée et union)

UN CONSEIL IMPORTANT

Dans la mesure du possible, utilisez toujours un opérateur de jointure normalisé Sql2 (mot clef JOIN).

En effet :

Les jointures faites dans la clause WHERE (ancienne syntaxe de 1986 !) ne permettent pas de faire la distinction de prime abord entre ce qui relève du filtrage et ce qui relève de la jointure.
Il est à priori absurde de vouloir filtrer dans le WHERE (ce qui restreint les données du résultat) et de voiloir "élargir" ce résultat par une jointure dans la même clause WHERE de filtrage.
La lisibilité des requêtes est plus grande en utilisant la syntaxe à base de JOIN, en isolant ce qui est du filtrage et de la jointure, mais aussi en isolant avec clarté chaque condition de jointures entre chaque couples de table.
L'optimisation d'exécution de la requête est souvent plus pointue du fait de l'utilisation du JOIN.
Lorsque l'on utilise l'ancienne syntaxe et que l'on supprime la clause WHERE a des fins de tests, le moteur SQL réalise le produit cartésiens des tables ce qui revient la plupart du temps à mettre à genoux le serveur !

Envoyé par Luc Orient

J'ajouterais que pour une jointure interne, la sémantique et les accès sont strictements identiques. Donc à mon avis, cette question est un point de détail et ne mérite vraiment pas qu'on en fasse tout un plat ...
Encore une fois je ne parle que des jointures internes ... les autres types de jointure ne peuvent s'exprimer que par la clause JOIN et là il n'y a plus matière à débat ...

Je ne suis pas sûr de bien comprendre ? Par exemple, les jointures externes peuvent tout à fait s'écrire dans le WHERE, sinon Oracle 8 ne serait pas capable de les gérer

.

**Luc Orient** · 16/08/2006, 21h11

Envoyé par Xo

...
Je ne suis pas sûr de bien comprendre ? Par exemple, les jointures externes peuvent tout à fait s'écrire dans le WHERE, sinon Oracle 8 ne serait pas capable de les gérer

.

Je connais pas Oracle ... On fait comment alors ?

Xo · 17/08/2006, 08h42

Dans le cours précédement cité sur les jointures, tu as les "anciennes" syntaxes pour les SGBD ne supportant pas JOIN

2.4.2. Mécanisme en jeu

D'anciennes syntaxes permettent de faire des jointures externes unilatérale. Par exemple, il n'est pas rare de rencontrer les syntaxes suivantes :
SELECT colonnes
FROM table_1 t1, table_2 t2
WHERE t1.id1 *= t2.id2
ou encore

SELECT colonnes
FROM table_1 t1, table_2 t2
WHERE t1.id1 (+)= t2.id2
Elles sont bien évidemment à proscrire si la syntaxe SQL 2 est disponible !

**kashue** · 17/08/2006, 10h14

J'ai appris à programmer une base de donnée grace à ce site du coup j'utilise Join souvent. Merci à developpez.com.

**Luc Orient** · 21/08/2006, 09h36

Envoyé par Xo

Dans le cours précédement cité sur les jointures, tu as les "anciennes" syntaxes pour les SGBD ne supportant pas JOIN

2.4.2. Mécanisme en jeu

J'ignorais complètement cette syntaxe ... C'est vrai qu'elle est loin d'être standard ...
Le SGBD que j'utilise (DB2 for z/OS) n'a accepté le JOIN qu'à partir de la V4 (actuellement il est en V8) et avant il n'y avait pas de moyen simple d'obtenir l'équivalent des jointures externes ...

**Lou Pitchoun** · 21/08/2006, 09h51

Salut,
J'ai appris à utiliser JOIN dans les requêtes SQL access.
En suivant une formation au CNAM cette année, j'ai utilisé les liaisons dans la clause WHERE.
J'utilise exclusivement JOIN dans mes bases Access.

**Luc Orient** · 21/08/2006, 10h00

Envoyé par Kikof

Salut,
...
En suivant une formation au CNAM cette année, j'ai utilisé les liaisons dans la clause WHERE.
...

Cela voudrait dire que le cours du CNAM n'est pas à niveau ?

**Lou Pitchoun** · 21/08/2006, 10h06

En fait, le support de cours est intitulé "SQL 92" enfin un truc du genre. Donc Le SQL normalisé si je ne m'abuse.
On a beaucoup utilisé les jointures dans le where (ce qui m'a un peu déstabilisé au début). Mais si mes souvenirs sont bons (alzheimer frappe à n'importe quel age), le JOIN était abordé. Il faudrait que je confirme ça. (j'ai mon cours à la maison donc ce sera pour demain.)

**Luc Orient** · 21/08/2006, 10h26

Pour moi un bon cours SQL sur les jointures devrait être du style :

"Je vous présente la norme en décrivant le JOIN et les différents types de jointure (INNER, OUTER, etc ).
Mais sachez, qu'il existe une autre syntaxe (le WHERE), en expliquant le pourquoi de cette double écriture, et que, au cours de votre vie professionnelle vous risquez d'y être confrontée, alors autant la connaître et la maîtriser ..."

Ensuite, passer en revue les différents SGBD en indiquant leur situation vis à vis de cette problématique ... Mais là ça nécessite une connaissance quasi encyclopédique ...