LEFT JOIN ou RIGHT JOIN : Interchangeables ?

Version imprimable

Voir 40 message(s) de cette discussion en une page

Bonjour à tous,

Récemment, je me suis intéressé aux types de jointures suivants*: LEFT JOIN et RIGHT JOIN.

Je comprends que ces deux types de jointures, appliqués à deux ensembles de données qui partagent des éléments en communs, sont utilisés pour sélectionner les éléments qui appartiennent à un ensemble et pas à l’autre.

Mais je me pose la question suivante: pour quelle raison existe-t-il deux façons d’exprimer ce critère de sélection ?

D’une façon générale:

Code:

1
2
3
        SELECT     ...
        FROM       REFERENCE
        LEFT JOIN  ATTRIBUT ON REFERENCE.key = ATTRIBUT.key

Est équivalent à:

Code:

1
2
3
        SELECT     ...
        FROM       ATTRIBUT
        RIGHT JOIN REFERENCE ON REFERENCE.key = ATTRIBUT.key

Et:

Code:

1
2
3
4
        SELECT     ...
        FROM       REFERENCE
        LEFT JOIN  ATTRIBUT ON REFERENCE.key = ATTRIBUT.key
        WHERE      ATTRIBUT.key is NULL

Est équivalent à:

Code:

1
2
3
4
        SELECT     ...
        FROM       ATTRIBUT
        RIGHT JOIN REFERENCE ON REFERENCE.key = ATTRIBUT.key
        WHERE      ATTRIBUT.key is NULL

Donc il est possible d’exprimer un même critère de sélection avec, au choix, l’un ou l’autre type de jointure (un LEFT JOIN ou un RIGHT JOIN).

Dans ces conditions, y a-t-il un avantage à utiliser une forme plutôt qu’une autre ?

Exemple concret sous MySql :

Je vais donner un exemple concret pour bien illustrer mon propos.

Considérons deux tables, liées par une jointure.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
SET foreign_key_checks = 0;
DROP TABLE IF EXISTS citoyen;
DROP TABLE IF EXISTS activite;
SET foreign_key_checks = 1;
 
CREATE TABLE activite
(
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(255),
    PRIMARY KEY(id),
    CONSTRAINT uc_name UNIQUE (name)
)
ENGINE=INNODB;
 
INSERT INTO activite SET name='comptable'; SELECT LAST_INSERT_ID() INTO @comptable;
INSERT INTO activite SET name='patissier'; SELECT LAST_INSERT_ID() INTO @patissier;
INSERT INTO activite SET name='peintre';   SELECT LAST_INSERT_ID() INTO @peintre;
INSERT INTO activite SET name='jardinier'; SELECT LAST_INSERT_ID() INTO @jardinier;
INSERT INTO activite SET name='plombier';  SELECT LAST_INSERT_ID() INTO @plombier;
INSERT INTO activite SET name='vitrier';   SELECT LAST_INSERT_ID() INTO @vitrier;
INSERT INTO activite SET name='policier';  SELECT LAST_INSERT_ID() INTO @policier;
INSERT INTO activite SET name='juge';      SELECT LAST_INSERT_ID() INTO @juge;
INSERT INTO activite SET name='sabotier';  SELECT LAST_INSERT_ID() INTO @sabotier;
 
CREATE TABLE citoyen
(
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(255),
    fk_activite INT,
    PRIMARY KEY(id),
    FOREIGN KEY (fk_activite) REFERENCES activite(id),
    CONSTRAINT uc_name UNIQUE (name)
)
ENGINE=INNODB;
 
INSERT INTO citoyen SET name='Paul',      fk_activite=@comptable;
INSERT INTO citoyen SET name='Denis',     fk_activite=@comptable;
INSERT INTO citoyen SET name='Vincent',   fk_activite=@patissier;
INSERT INTO citoyen SET name='Eric',      fk_activite=@peintre;
INSERT INTO citoyen SET name='Laurent',   fk_activite=@peintre;
INSERT INTO citoyen SET name='Nicolas',   fk_activite=@jardinier;
INSERT INTO citoyen SET name='Valerie',   fk_activite=@plombier;
INSERT INTO citoyen SET name='Kathy',     fk_activite=@vitrier;
INSERT INTO citoyen SET name='Stephanie'; 
INSERT INTO citoyen SET name='Jean';

Tous les citoyens, avec leur activité associée, même s'ils n'ont pas d'activité.

Code:

1
2
3
    SELECT      citoyen.name, activite.name
    FROM        citoyen
    LEFT JOIN   activite ON citoyen.fk_activite = activite.id;

Code:

1
2
3
    SELECT      citoyen.name, activite.name
    FROM        activite
    RIGHT JOIN  citoyen ON citoyen.fk_activite = activite.id;

Toutes les activités, avec les citoyens associés, même pour les activités qui ne sont assurées par personne.

Code:

1
2
3
    SELECT      activite.name, citoyen.name
    FROM        activite
    LEFT JOIN   citoyen ON citoyen.fk_activite = activite.id;

Code:

1
2
3
    SELECT      activite.name, citoyen.name
    FROM        citoyen
    RIGHT JOIN  activite ON citoyen.fk_activite = activite.id;

Tous les citoyens qui n'ont pas d'activité.

Code:

1
2
3
4
    SELECT      citoyen.name, activite.name
    FROM        citoyen
    LEFT JOIN   activite ON citoyen.fk_activite = activite.id
    WHERE       activite.id IS NULL;

Code:

1
2
3
4
    SELECT      citoyen.name, activite.name
    FROM        activite
    RIGHT JOIN  citoyen ON citoyen.fk_activite = activite.id
    WHERE       activite.id IS NULL;

Toutes les activités qui ne sont assurées par aucun citoyen.

Code:

1
2
3
4
    SELECT      activite.name
    FROM        activite
    LEFT JOIN   citoyen ON citoyen.fk_activite = activite.id
    WHERE       citoyen.id IS NULL;

Code:

1
2
3
4
    SELECT     activite.name
    FROM       citoyen
    RIGHT JOIN activite ON citoyen.fk_activite = activite.id
    WHERE      citoyen.id is NULL;

Les 4 requêtes présentées peuvent être exprimées avec l’un ou l’autre type de jointure (LEFT JOIN ou RIGHT JOIN). Dans ces conditions, pourquoi a-t-on inventé deux façons d’exprimer la même chose?

Je pense que quelque chose m’échappe. Mais je ne vois pas ce que cela peut être.

Merci à tous,

Denis

01/04/2012, 13h56
sevyc64
Citation:

Envoyé par WinNew

...appliqués à deux ensembles de données qui partagent des éléments en communs, sont utilisés pour sélectionner les éléments qui appartiennent à un ensemble et pas à l’autre....

Déjà, en commençant par là, tu as tout faux, ce n'est pas du tout ça.

LEFT JOIN --> Tous les éléments de la table de gauche avec éventuellement pour chaque élément, les éléments de la table de droite correspondants, s'il y a correspondance
RIGHT JOIN --> Tous les éléments de la table de droite avec éventuellement pour chaque élément, les éléments de la table de gauche correspondants, s'il y a correspondance
Citation:
Mais je me pose la question suivante: pour quelle raison existe-t-il deux façons d’exprimer ce critère de sélection ?

D’une façon générale:

Code:

1 2 3 SELECT ... FROM REFERENCE LEFT JOIN ATTRIBUT ON REFERENCE.key = ATTRIBUT.key

Est équivalent à:

Code:

1 2 3 SELECT ... FROM ATTRIBUT RIGHT JOIN REFERENCE ON REFERENCE.key = ATTRIBUT.key
Dans ce cas bien précis, avec une seule jointure, effectivement les résultats devraient identiques. Mais les requêtes sont rarement aussi simplistes.

Imagine une requete avec une dizaine ou une quinzaine de jointures qui partent dans tous les sens, a partir de la table principale, mais aussi des tables jointes. Tu dois imaginer ta requete comme étant un arbre, la 1er table (celle du From) étant le tronc, les autres étant les branches.
Si tu part avec la table Attributs comme tronc, tu n'auras pas les mêmes résultats que si tu part de la table Référence, car ton référentiel ne sera pas le même. Le cas que tu donne étant un cas particulier de ce schéma.
02/04/2012, 09h06
StringBuilder

Citation:

Envoyé par sevyc64

Dans ce cas bien précis, avec une seule jointure, effectivement les résultats devraient identiques. Mais les requêtes sont rarement aussi simplistes.

Imagine une requete avec une dizaine ou une quinzaine de jointures qui partent dans tous les sens, a partir de la table principale, mais aussi des tables jointes. Tu dois imaginer ta requete comme étant un arbre, la 1er table (celle du From) étant le tronc, les autres étant les branches.
Si tu part avec la table Attributs comme tronc, tu n'auras pas les mêmes résultats que si tu part de la table Référence, car ton référentiel ne sera pas le même. Le cas que tu donne étant un cas particulier de ce schéma.

Quand on part du bon point de départ, en suivant la règle "en prendre le moins possible le plus tôt possible", on n'a jamais besoin du RIGHT JOIN (ou presque). En 13 ans d'expérience, où j'écrit quotidiennement des requêtes, j'ai dû me servir 2 ou 3 fois de RIGHT JOIN. A vrai dire, autant que de fois où je me suis servi de FULL JOIN, c'est à dire vraiment très rarement.
02/04/2012, 10h03
WinNew

@sevyc64

Bonjour Yves,

Merci pour ta réponse. J'ai l'habitude de me représenter les choses visuellement. Je vais essayer de formaliser graphiquement une jointure par un arbre.

Quand j'aurais trouvé une manière claire de formaliser ces notions, je vais l'exposer sur le forum.

Cordialement,

Denis
02/04/2012, 10h07
WinNew

@StringBuilder

Bonjour,

Je te remercie pour ton intervention. Si je comprends bien le choix de la "formule" (LEFT JOIN ou RIGHT JOIN) la plus appropriée dépend aussi des tailles respectives des ensembles de données à manipuler.

Cordialement,

Denis
02/04/2012, 11h54
Waldar

Non pas d'histoire de volumétrie.
Les syntaxes LEFT OUTER JOIN et RIGHT OUTER JOIN sont similaires mais s'appliquent comme vous l'avez compris en fonction de l'ordre de ce qu'on lui donne.

J'imagine que les deux ont été créé pour laisser plus de souplesse aux développeurs, maintenant d'expérience je vous conseille d'en choisir un et de n'utiliser que celui là, quand on retrouve des LEFT et RIGHT dans la même requête ça peut devenir difficile à relire.

LEFT JOIN possède un avantage certain : il se lit naturellement, de haut en bas et de gauche à droite.
02/04/2012, 13h40
StringBuilder

Citation:

Envoyé par WinNew

Si je comprends bien le choix de la "formule" (LEFT JOIN ou RIGHT JOIN) la plus appropriée dépend aussi des tailles respectives des ensembles de données à manipuler.

Non en effet, il n'y a pas de notion de volumétrie.

En revanche, un adage SQL, c'est de filtrer au maximum le plus tôt possible.

Hors, autant le LEFT JOIN se traduit littéralement "pour ma table a, ramène toutes les lignes de la table b, sinon null"
=> Je ne rajoute pas de lignes dans mon résultat, je respecte donc l'adage

Alors que le RIGHT JOIN se traduit littéralement "pour la table a, ramène toutes les lignes qui ont un lien vers b, et complète avec des nulls pour les lignes de b qui n'ont pas de lien avec a"
=> Clairement, on va rajouter des lignes dans le résultat. On préférera donc filtrer sur B avant A.

Enfin, c'est mon interprétation personnelle.
02/04/2012, 13h57
CinePhil

Citation:

En revanche, un adage SQL, c'est de filtrer au maximum le plus tôt possible.

Hors, autant le LEFT JOIN se traduit littéralement "pour ma table a, ramène toutes les lignes de la table b, sinon null"
=> Je ne rajoute pas de lignes dans mon résultat, je respecte donc l'adage

Alors que le RIGHT JOIN se traduit littéralement "pour la table a, ramène toutes les lignes qui ont un lien vers b, et complète avec des nulls pour les lignes de b qui n'ont pas de lien avec a"
=> Clairement, on va rajouter des lignes dans le résultat. On préférera donc filtrer sur B avant A.

J'aime bien ton adage dans sa philosophie mais je ne pense pas que ça change grand chose réellement dans le SGBD d'utiliser LEFT ou RIGHT, au niveau des performances.
Il est même possible qu'un optimiseur performant récrive logiquement la requête dans le sens le plus approprié.

Je te rejoins aussi sur la rareté de l'emploi du RIGHT par rapport à l'écrasante majorité du LEFT. N'y voyez aucune connotation politique de ma part en ces temps électoraux ! En ce domaine, le résultat est bien moins certain ! :D
02/04/2012, 14h03
sevyc64

Citation:

Envoyé par WinNew

J'ai l'habitude de me représenter les choses visuellement. Je vais essayer de formaliser graphiquement une jointure par un arbre.

Non pas une, mais un certain nombre de jointures.
Avec une seule jointure, tu as un tronc et une branche dans l'alignement du tronc, ça ne visualise pas grand chose. Par contre avec un certain nombre de jointures (et de "sous-jointures", de "sous-sous-jointures", etc) ça devient intéressant.

Attention aussi à une faute courante, même les pros la font et ne comprennent pas toujours d’où vient leur bug, sur une jointure externe (Left ou Right), de mettre dans la clause WHERE une condition sur la table jointe sans tenir compte des valeurs nulles revient à faire une jointure interne (INNER JOIN) :

Code:

SELECT * FROM A LEFT JOIN B ON A.FK=B.PK WHERE B.Champ=Valeur

n'est plus une jointure gauche mais est équivalent à

Code:

SELECT * FROM A INNER JOIN B ON A.FK=B.PK WHERE B.Champ=Valeur

Pour que ça reste une jointure gauche il faut écrire

Code:

SELECT * FROM A LEFT JOIN B ON A.FK=B.PK WHERE B.Champ IS NULL OR B.Champ=Valeur
02/04/2012, 14h08
CinePhil

Représenter visuellement des jointures ?
Faire un MCD de la BDD ! :mrgreen:
02/04/2012, 14h11
al1_24
Citation:

Envoyé par sevyc64

Pour que ça reste une jointure gauche il faut écrire

Code:

SELECT * FROM A LEFT JOIN B ON A.FK=B.PK WHERE B.Champ IS NULL OR B.Champ=Valeur

De cette manière, on sélectionne aussi les lignes de la table B où B.Champ est null, ce qui n'est pas le but recherché

Il vaut mieux écrire :
Code:

1 2 3 4 5 6 SELECT * FROM A LEFT JOIN B ON A.FK = B.PK AND B.Colonne = Valeur
Ce qui met bien en évidence la restriction opérée sur la table B avant jointure
02/04/2012, 14h17
CinePhil

Oui c'est ce que j'explique dans mon article de blog.
02/04/2012, 14h19
WinNew
Bonjour à tous,

Je crois que j'ai finalement compris ces deux types de jointures.

Supposons que l'on a trois tables "A", "B" et "C".
- "A" est liée à "B" par une jointure. A <-> B
- "A" est liée à "C" par une jointure. A <-> C
Sur chaque illustration, la "table de référence" pour la jointure est de couleur rouge pâle.

D'une façon générale:
Code:

1 2 3 SELECT ... FROM table_de_référence LEFT JOIN autre_table ON ...;
Code:

1 2 3 SELECT ... FROM autre_table RIGHT JOIN table_de_référence ON ...;
LEFT JOIN
Code:

1 2 3 SELECT ... FROM A LEFT JOIN B ON A.key.B.key;
https://lh3.googleusercontent.com/-v...800/sqj1-A.gif

RIGHT LOIN
Code:

1 2 3 SELECT ... FROM A RIGHT JOIN B ON A.key.B.key;
https://lh5.googleusercontent.com/-g...800/sqj1-B.gif

Combinaison d'un LEFT JOIN et d'un RIGHT JOIN
Code:

1 2 3 4 SELECT ... FROM A LEFT JOIN B ON A.key = B.key RIGHT JOIN C ON A.key = C.key;
Il faut évaluer les jointures dans l'ordre de déclaration de ces dernières. Dans cet exemple, on effectue d'abord le LEFT JOIN. Puis on effectue le RIGHT JOIN sur le résultat obtenu précédemment.

https://lh4.googleusercontent.com/-C...800/sqj1-C.gif

Voili, voilou,

Vous confirmez?

Cordialement,

Denis
02/04/2012, 14h24
sevyc64
Citation:

Envoyé par al1_24

De cette manière, on sélectionne aussi les lignes de la table B où B.Champ est null, ce qui n'est pas le but recherché

Dans le cas ou un enregistrement B serait bien retourné mais avec le champ en question nul, effectivement.
Citation:
Envoyé par al1_24

Il vaut mieux écrire :

Code:

1 2 3 4 5 6 SELECT * FROM A LEFT JOIN B ON A.FK = B.PK AND B.Colonne = Valeur

Ce qui met bien en évidence la restriction opérée sur la table B avant jointure
C'est une solution aussi. Et elle est plus propre.
Mais peut-être pas toujours aussi facilement identifiable ou compréhensible dans des requêtes complexes où on aime rassembler tout ce qui est purement filtre dans la clause where (surtout si ce filtre est construit dynamiquement).

Bref, le langage SQL est un langage puissant, performant mais complexe et qui peut se révélé assez facilement contre-productif si on ne fait pas attention à ce que l'on fait.
02/04/2012, 14h37
CinePhil

WinNew, bravo pour tes schémas très clairs ! :ccool:

Par contre, je ne suis pas sûr de la validité du dernier.
Fais des tests avec des données pour le vérifier.
02/04/2012, 14h38
Waldar
Oui WinNew c'est correct, mais dans le fond notez bien qu'on s'en fout.
Vous êtes en train de vous demander s'il vaut mieux écrire 10/2 ou bien 0.5*10.

Ecrire :
Code:

1 2 3 4 SELECT ... FROM A LEFT JOIN B ON A.KEY = B.KEY RIGHT JOIN C ON A.KEY = C.KEY;
Est précisément, à mon sens, ce qu'il faut éviter de coder.

Autant lever les ambiguïtés et écrire :
Code:

1 2 3 4 SELECT ... FROM C LEFT JOIN A ON A.KEY = C.KEY LEFT JOIN B ON B.KEY = A.KEY;
02/04/2012, 15h45
StringBuilder

Citation:

Envoyé par sevyc64

Dans le cas ou un enregistrement B serait bien retourné mais avec le champ en question nul, effectivement.

C'est une solution aussi. Et elle est plus propre.

Attention, certains SGBD (Access tout du moins) n'acceptent pas les valeurs littérales (ou paramètres) dans la clause "ON".

Je trouve cela effectivement logique : si c'est une "valeur" et non un champ, alors il ne s'agit pas d'un élément de jointure, mais bien d'un élément de filtre, et n'a donc sa place que dans le "WHERE".

Citation:

Envoyé par CinePhil

WinNew, bravo pour tes schémas très clairs ! :ccool:

Par contre, je ne suis pas sûr de la validité du dernier.
Fais des tests avec des données pour le vérifier.

Salut,

J'ai vérifié en faisant des tests sur une base de test avant de poster :zoubi:

Pour information, voici la petite base de test :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
SET foreign_key_checks = 0;
DROP TABLE IF EXISTS citoyen;
DROP TABLE IF EXISTS activite;
DROP TABLE IF EXISTS voiture;
SET foreign_key_checks = 1;
 
CREATE TABLE activite
(
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(255),
    PRIMARY KEY(id),
    CONSTRAINT uc_name UNIQUE (name)
)
ENGINE=INNODB;
 
INSERT INTO activite SET name='comptable'; SELECT LAST_INSERT_ID() INTO @comptable;
INSERT INTO activite SET name='patissier'; SELECT LAST_INSERT_ID() INTO @patissier;
INSERT INTO activite SET name='peintre';   SELECT LAST_INSERT_ID() INTO @peintre;
INSERT INTO activite SET name='jardinier'; SELECT LAST_INSERT_ID() INTO @jardinier;
INSERT INTO activite SET name='plombier';  SELECT LAST_INSERT_ID() INTO @plombier;
INSERT INTO activite SET name='vitrier';   SELECT LAST_INSERT_ID() INTO @vitrier;
INSERT INTO activite SET name='policier';  SELECT LAST_INSERT_ID() INTO @policier;
INSERT INTO activite SET name='juge';      SELECT LAST_INSERT_ID() INTO @juge;
INSERT INTO activite SET name='sabotier';  SELECT LAST_INSERT_ID() INTO @sabotier;
 
CREATE TABLE voiture
(
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(255),
    PRIMARY KEY(id),
    CONSTRAINT uc_name UNIQUE (name)
)
ENGINE=INNODB;
 
INSERT INTO voiture SET name='Renault'; SELECT LAST_INSERT_ID() INTO @Renault;
INSERT INTO voiture SET name='Peugeot'; SELECT LAST_INSERT_ID() INTO @Peugeot;
INSERT INTO voiture SET name='BMW';     SELECT LAST_INSERT_ID() INTO @BMW;
INSERT INTO voiture SET name='Toyota';  SELECT LAST_INSERT_ID() INTO @Toyota;
INSERT INTO voiture SET name='Porshe';  SELECT LAST_INSERT_ID() INTO @Porshe;
 
CREATE TABLE citoyen
(
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(255),
    fk_activite INT,
    fk_voiture INT,
    PRIMARY KEY(id),
    FOREIGN KEY (fk_activite) REFERENCES activite(id),
    FOREIGN KEY (fk_voiture) REFERENCES voiture(id),
    CONSTRAINT uc_name UNIQUE (name)
)
ENGINE=INNODB;
 
INSERT INTO citoyen SET name='Paul',      fk_activite=@comptable,  fk_voiture=@Renault;
INSERT INTO citoyen SET name='Denis',     fk_activite=@comptable,  fk_voiture=@Renault;
INSERT INTO citoyen SET name='Vincent',   fk_activite=@patissier,  fk_voiture=@Peugeot;
INSERT INTO citoyen SET name='Eric',      fk_activite=@peintre,    fk_voiture=@Peugeot;  
INSERT INTO citoyen SET name='Laurent',   fk_activite=@peintre;  
INSERT INTO citoyen SET name='Nicolas',   fk_activite=@jardinier;
INSERT INTO citoyen SET name='Valerie',   fk_activite=@plombier,   fk_voiture=@Toyota; 
INSERT INTO citoyen SET name='Kathy',     fk_activite=@vitrier,    fk_voiture=@Toyota;  
INSERT INTO citoyen SET name='Stephanie';                        
INSERT INTO citoyen SET name='Jean',                               fk_voiture=@BMW;

A+

Sinon, tu oublies le plus important :

J'ai nommé l'absolument inutile "FULL OUTER JOIN" :
Code:

1 2 3 4 5 6 7 8 9 10 11 create table nom (pers_id int, nom varchar2(12)); create table prenom (pers_id int, prenom varchar2(12)); insert into nom values (1, 'DUPUIS'); insert into nom values (2, 'DUPONT'); insert into prenom values (1, 'Albert'); insert into prenom values (3, 'Jean'); select nvl(nom.pers_id, prenom.pers_id) pers_id, prenom.prenom, nom.nom from nom full outer join prenom on prenom.pers_id = nom.pers_id;
Aujourd'hui, c'est la troisième 3 que je l'utilise : 2 fois afin de dire qu'il existe, et 1 fois parce que j'en ai réellement eu besoin, mais j'ai capitulé à cause des performances trop catastrophiques, j'ai préféré faire des requêtes imbriquées crades au possible, mais 1000x plus rapides.

-- Edit : Ca me reviens, je m'en suis servi une fois "pour de vrai" dans le cadre d'une fusion de deux bases de données : j'avais la même clé dans plusieurs tables différentes, et il fallait créer une nouvelle table en joignant les données des deux tables. Mais le FULL OUTER JOIN, utilisé par personne (puisque méconnu, et facilement remplaçable par des syntaxes plus courantes), n'est absolument pas optimisé, et donc j'ai dû capituler très rapidement au profit d'une usine à gaz.

02/04/2012, 16h06
WinNew
Citation:
Envoyé par Waldar

Oui WinNew c'est correct, mais dans le fond notez bien qu'on s'en fout.
Vous êtes en train de vous demander s'il vaut mieux écrire 10/2 ou bien 0.5*10.

Ecrire :

Code:

1 2 3 4 SELECT ... FROM A LEFT JOIN B ON A.KEY = B.KEY RIGHT JOIN C ON A.KEY = C.KEY;

Est précisément, à mon sens, ce qu'il faut éviter de coder.

Autant lever les ambiguïtés et écrire :

Code:

1 2 3 4 SELECT ... FROM C LEFT JOIN A ON A.KEY = C.KEY LEFT JOIN B ON B.KEY = A.KEY;
Salut,

Oui, effectivement, autant utiliser la même démarche de façon systématique...

Dans le cas d'une "suite de relations linéraire", il est toujours possible de partir d'une extrémité pour aller vers l'autre. Dans ce cas, il est possible d'utiliser systématiquement le même type de jointure (uniquement du LEFT ou du RIGHT) pour joindre toutes les tables.

https://lh3.googleusercontent.com/-h...800/sql111.gif

Mais, dans le cas d'un ensemble de relations "non linéaires", il me semble que l'on est obligé d'utiliser les deux types de jointure (LEFT JOIN et RIGHT JOIN) simultanément (pour joindre toutes les tables).

https://lh6.googleusercontent.com/-R...800/sql222.gif

En fait, non. Ce que je viens d'écrire plus haut est faux... On ne peut pas généraliser. Tout dépend de ce que l'on veut faire.

Denis

Voir 40 message(s) de cette discussion en une page