Discussion :

[Michel.Priori]

Quelle différence de logique de traitement voyez vous entre :

Code :

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

1
2
3
4
SELECT *
FROM entiers E
RIGHT JOIN Pairs P ON P.valeur= E.valeur
RIGHT JOIN impairs I ON I.valeur= E.valeur

et

Code :

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

1
2
3
4
SELECT *
FROM entiers E
RIGHT JOIN impairs I ON I.valeur= E.valeur
RIGHT JOIN Pairs P ON P.valeur= E.valeur

?

De manière étrange les 2 requêtes :
1- produisent des résultats
2- produisent des résultats différents
3- ne produisent pas de résultat logique par rapport à l'écriture

*****
Pour ceux qui veulent s'amuser :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
CREATE TABLE Entiers (valeur int) ;
GO
CREATE TABLE Pairs (valeur int);
GO
CREATE TABLE impairs (valeur int);
 
GO
INSERT INTO Entiers VALUES (0),(1),(2);
INSERT INTO Pairs VALUES (0),(2),(4),(6),(8);
INSERT INTO impairs VALUES (0),(1),(3),(5),(7),(9);
 
SELECT *
FROM entiers E
RIGHT JOIN Pairs P ON P.valeur= E.valeur
RIGHT JOIN impairs I ON I.valeur= E.valeur 
--intersect
SELECT *
FROM entiers E
RIGHT JOIN impairs I ON I.valeur= E.valeur
RIGHT JOIN Pairs P ON P.valeur= E.valeur

Pensez-vous que ce soit un bug dans la résolution de l'algèbre relationnel de SQL serveur ?

[SQLpro]

Ce résultat est parfaitement logique. Le but de la jointure externe est de préserver les lignes de la table de droite/gauche/les deux en fonction du mot clef LEFT/RIGHT/FULL.
Mais l'opération n'est pas commutative, contrairement à l'équi-jointure interne.
En faisant un double RIGTH OUTER JOIN, vous préservez donc la dernière opération... Pas la première !

A +

[Michel.Priori]

Merci de ta réponse rapide.
Cependant cela ne répond que très partiellement aux points soulevés :
* Quelle différence de logique de traitement voyez vous ?
* De manière étrange les 2 requêtes :
1- produisent des résultats
2- produisent des résultats différents
3- ne produisent pas de résultat logique par rapport à l'écriture
* Pensez-vous que ce soit un bug dans la résolution de l'algèbre relationnel de SQL serveur ?


Commentaires sur ta réponse :

Ce résultat est parfaitement logique.

en quoi le résultat est logique ? lequel ? le premier ou le deuxième ?
Même si je remplace le mot "résultat" par "comportement" dans ta phrase, je n'approuve toujours pas.

Le but de la jointure externe est de préserver les lignes de la table de droite/gauche/les deux en fonction du mot clef LEFT/RIGHT/FULL.
Mais l'opération n'est pas commutative, contrairement à l'équi-jointure interne.

c'est marqué où ça ? des références ?
Pour moi le langage SQL est de pouvoir définir le but SANS préciser le comment ; du coup la non commutativité ...
Il n'en reste pas moins évident que

Code :

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

T1 right join T2

est équivalent à

Code :

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

T2 Left join T1

et que bien sûr la commutation des membres doit suivre le "sens" de la jointure. On ne va pas reprendre ici les bases du langage !

En faisant un double RIGTH OUTER JOIN, vous préservez donc la dernière opération... Pas la première !

Et pourquoi la dernière et pas celle du milieu ?
Qu'est ce qu'on fait de la première et des autres ?
Avec les resultset à l'appuis, merci de détailler ce qu'on garde et ce qu'on garde pas...

A +

j'espère bien

[SQLpro]

Il serait peut être bon pour vous de commencer par apprendre le langage SQL, parce que là c'est un cous complet qu'il vous faut, et non pas un tuto a la con, comme on en trouve beaucoup sur Internet !

Pour comprendre par vous même, il suffit de décomposer... :

Code :

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

1
2
3
4
5
6
7
SELECT *
FROM   (SELECT E.valeur AS E_valeur, P.valeur AS P_valeur     
        FROM   entiers AS E
               RIGHT OUTER JOIN Pairs AS P 
	                 ON P.valeur= E.valeur) AS T 
       RIGHT OUTER JOIN impairs AS I 
	         ON I.valeur= T.E_valeur;

=>

Code :

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

1
2
3
4
SELECT E.valeur AS E_valeur, P.valeur AS P_valeur     
FROM   entiers AS E
       RIGHT OUTER JOIN Pairs AS P 
             ON P.valeur= E.valeur

Dont le résultat T :

Code :

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

1
2
3
4
5
6
7
e_valeur    P_valeur
----------- -----------
0           0
2           2
NULL        4
NULL        6
NULL        8

est joint comme ceci :

Code :

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

1
2
3
4
5
 
SELECT *
FROM   T 
       RIGHT OUTER JOIN impairs AS I 
	         ON I.valeur= T.E_valeur;

À ce stade le seul élément de l'ensemble T ayant une stricte correspondance avec la table des impairs est le zéro. C'est pourquoi la solution finale montre toutes les valeurs de la table à droite avec comme seule ligne complète le zéro :

Code :

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

1
2
3
4
5
6
7
8
e_valeur    P_valeur    valeur
----------- ----------- -----------
0           0           0
NULL        NULL        1
NULL        NULL        3
NULL        NULL        5
NULL        NULL        7
NULL        NULL        9

Vous devez alors comprendre (enfin, espérons-le !) le fait que la jointure externe n'est pas commutative (si vous avez quelques notions de math, essentielles pour aborder l'informatique) !

NOTA : il est préférable de toujours mettre le mot clef OUTER dans les jointures externe, car c'est cela qui est fondamentale à comprendre, le fait que vous faites une jointure externe !!! Jointure gauche, jointure droite étant des abréviations stupides qui ne veulet rien dire !


A +

[Michel.Priori]

Super merci pour cette explication très détaillée et didactique.

Je n'étais jamais tombé sur ce cas de requête ; en général les outer join sont orientés de manière plus naturelle :
A -> B -> C ou A <- B -> C mais pas A -> B <- C
Du coup la non commutativité ne mettait jamais apparu (et je n'ai jamais rien lu à ce sujet ou alors j'ai oublié ).

Traiter les jointures non commutatives dans l'ordre de l'écriture est donc la solution retenue par le moteur (et à partir de là peuvent en découler des options dans les plans d'exécution)

J'ai mis pas de temps à simplifier le problème et je me suis perdu dans les considérations du code initial .

Nota à propos de l'écriture : si les abréviations d'écriture existe c'est pour s'en servir ! Ici l'objectif était de faire le script le plus court possible.
Mais si c'était si important, voire stupide, pourquoi le langage l'accepte ?
Oui je me sert de *, je n'écrit pas toujours AS (notamment pour les tables, comme sous Oracle) et oui OUTER est optionnel, de plus je fais parti de ceux qui regrettent l'absence de USING dans les jointures de chez SQL server.

Ceci étant dit, ça ne change pas le fait que la démonstration ici faite est parfaite.
Encore merci.

[SQLpro]

Traiter les jointures non commutatives dans l'ordre de l'écriture est donc la solution retenue par le moteur (et à partir de là peuvent en découler des options dans les plans d'exécution)

ATTENTION : ce n'est pas un choix du moteur qui lui peut faire ce qu'il veut. C'est simplement une règle de non commutativité de l'algèbre relationnelle.
Dans certains de mes cours avancés sur le SQL je montre comment la commutativité peut modifier le comportement d'une requête qui, pour la plupart des gens, aurait été écrite avec des sous requêtes, mais n'en a finalement pas besoin, et les performances sont bien évidemment tout autre !

Nota à propos de l'écriture : si les abréviations d'écriture existe c'est pour s'en servir ! Ici l'objectif était de faire le script le plus court possible.
Mais si c'était si important, voire stupide, pourquoi le langage l'accepte ?

C'est une nécessité...

Oui je me sert de *, je n'écrit pas toujours AS (notamment pour les tables, comme sous Oracle)

Oracle est un des SGBDR qui suit le moins la norme ce qui l'a fait rejeté depuis de nombreuses années et aujourd'hui ils s'en mordent les doigts et tente de rattraper le passé (dans la nouvelle version, il y a le support des noms de 128 caractères et les collations...). En particulier l'interdiction du AS pour les alias de table est épouvantable...

et oui OUTER est optionnel, de plus je fais parti de ceux qui regrettent l'absence de USING dans les jointures de chez SQL server.

Le USING peut avoir de l'intérêt, mais le NATURAL JOIN est une vaste connerie que la norme à d'ailleurs rendu obsolète dans la version suivante de sa parution à cause des dégâts que cela à occasionné !

Ceci étant dit, ça ne change pas le fait que la démonstration ici faite est parfaite.
Encore merci.

A +

[Invité]

dans la nouvelle version, il y a le support des noms de 128 caractères et les collations...

ENFIN !

[SQLpro]

ENFIN !

Un peu tard... Les entreprises fuient Oracle !

A +