Discussion :

[UbiK]

Bonjour,

Je vois souvent dans ce forum des requetes avec des INNER JOIN ou LEFT JOIN ou ce genre de truc . Etant complètement immergé dans le monde Oracle (ou je n'ai jamais vu une chose pareil pour l'instant mais plutot des jointures du type table1.champA=table2.champB et aucune de mes docs n'en parle) je me posais les questions suivantes :
- Est-ce que ces expressions sont normalisés SQL2 ou 3 ? Peuvent elles alors fonctionner sous différends sgbd sans retoucher le code ? Si non quels sont les sgbd qui utilisent ce type de synthaxe ?
- Quel est l'avantage, s'il y-en a un, d'utiliser ce type d'expression ? Le moteur sql traite il alors la requête différemment ? Les performances s'en ressentent elles ?

Merci d'éclairer ma curiosité

[Maxence HUBICHE]

Ben, à ce que j'ai compris, il s'agit d'une norme SQL2. (SQLPro me reprendra si je dis des bétises... )

L'avantage étant d'éviter le produit cartésien..
Ainsi un requete comme suit :

Code :

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

Select T1.* from T1 INNER JOIN T2 ON T1.ID=T2.ID

parce que là, on fait un travail uniquement sur les éléments joint
est plus performante qu'une requête

Code :

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

SELECT T1.* FROM T1, T2 WHERE T1.ID=T2.ID

qui fait un produit cartésien avant de ne garder que les lignes dont les élément joints sont communs.

C'est ce que j'ai compris

[SQLpro]

La clause JOIN est en effet un élément normatif depuis SQL 2 (1992) !

Certains SGBDR vieillots comme Oracle ou SQL Server, avait implanté une syntaxe différente avant que cette norme soit effective. Oracle à pris beaucoup de retard sur le sujet...

Les avantages de ce type de jointure sont incommensurables !
Certaines jointures normalisées ne peuvent être effectué par les anciennes syntaxes. Il en est ainsi du NATURAL JOIN et des non équi jointures externe.

De plus cette syntaxe est bien plus claire puisqu'elle distingue ce qui est de la jointure et ce qui relève du filtre.

Enfin elle est plus optimisée que l'ancienne syntaxe du fait que l'optimiseur s'attende à trouver dans les clauses ON des jointures des colonnes indexées alors que ce n'est pas systématiquement le cas dans le filtre WHERE.

A lire sur le sujet :
http://sqlpro.developpez.com/SQL_AZ_3.html#JOIN_syntaxe

etrait :
"UN CONSEIL IMPORTANT

Dans la mesure du possible, utilisez toujours un opérateur de jointure normalisé (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 !
"

A +

Frédéric BROUARD, expert SQL / bases de données
Livre 'SQL' la référence - Campus Press éditeur
* http://sqlpro.developpez.com/bookSQL.html *
site web 'SQLpro' http://sqlpro.developpez.com/

[UbiK]

Merci à tous les 2