Discussion :

[AurelienG_]

Bonjour.

Apres plusieurs années de développement ponctuel, j'ai décidé de mettre à jour mes connaissances en SQL.
J'ai découvert que la clause WHERE avait été remplacée par la clause JOIN pour séparer les jointures des critères.

Apres plusieurs lectures de tutoriels, j'ai compris le principe d'utilisation et sa syntaxe pour une jointure classique.
Mais comment effectuer plusieurs jointures sur plusieurs tables. Ci-dessous un exemple pour comprendre

Avec la clause WHERE

Code :

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

1
2
3
4
5
6
7
SELECT T1.Champ, T2.Champ, T3.Champ, T4.Champ
FROM T1, T2, T3, T4
WHERE T1.FK = T2.PK			
AND	T2.FK = T3.PK			
AND	T3.FK = T4.PK			
AND	Critères de selection			
…

Avec la clause INNER

Code :

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

1
2
3
4
5
6
7
SELECT	T1.Champ, T2.Champ, T3.Champ, T4.Champ
FROM T1
INNER JOIN T2 ON T1.FK = T2.PK	
INNER JOIN T3 ON T2.FK = T3.PK	
INNER JOIN T4 ON T3.FK = T4.PK	
WHERE	Critères de selection			
…

Il me faut lier les tables de T1 vers T4 pour récupérer les propriétés et les valeurs associées
Je pense pas que ma syntaxe soit correcte (du moins au niveau logique car apres ca reste juste de la sémantique )
J'ai beau rechercher mon cas je ne trouve rien qui m'explique au dela de la jointure simple entre 2 tables.

Pour vous faire une idée du résultat, la table T1 contient 700 lignes, je devrais en avoir au max 700 en sortie, or j'en ai + de 60K
A quoi cela est du ? Comment corriger ?

Merci pour votre aide.

[tatayo]

Bonjour,
Pour moi la syntaxe de la deuxième requête est correcte, et "correspond" à la première requête.
Pour ce qui est du résultat, si tu as 700 lignes dans T1, et si chaque ligne de T1 a 2 lignes correspondantes dans T2, idem de T2 vers T3 et T3 vers T4, le résultat aura 700*2*2*2 lignes, soit 5600 lignes (sans tenir compte des restrictions dans le WHERE, bien sûr).

Donc sans avoir de jeu de test, on ne peux pas savoir ce qui ne va pas dans la requête... mais ce n'est pas (à priori) un problème de jointure.

Tatayo.

[Michel]

Bonjour.

Pour vous faire une idée du résultat, la table T1 contient 700 lignes, je devrais en avoir au max 700 en sortie, or j'en ai + de 60K.

Entièrement c'accord avec Tatayo
Si les 700 lignes de la première table donnent700 lignes à la fin j'ai envie de dire qu'y à correspondance unique entre les champs ce chaque table et donc qu'une seule table aurait suffit; ce qui semble absurde.
La seule in connue qui reste dans ton problème se cache dans "Critères de selection " et c'est peut-être là qu'est l'os comme on dit en Grèce !

[AurelienG_]

Pour apporter plus d'infos, la base sur laquelle je travaille ne dispose d'aucune clé étrangère entre les tables alors qu'elle est en fonctionnement depuis plusieurs années. J'ai pensé à utiliser une liaison de type NATURAL JOIN, mais les champs n'ont pas les mêmes noms, et dans certains cas, pas le même format (smallint(4) dans une table pour int(6) dans l'autre,....)

N'ayant pas de jeu de test à proximité je vous tiendrai informé dès lundi. (Ahhh le week-end....)

Si j'ai bien compris le fonctionnement du INNER JOIN :
- Il ne peut y avoir qu'une seule table dans la clause FROM
- La table dans la clause FROM doit être en lien avec au moins un champ dans la clause SELECT.
- Chaque jointure ajoutée dans un JOIN doit être en lien avec une des jointures précédentes.

Merci pour vos reponses.

[escartefigue]

Entièrement c'accord avec Tatayo
Si les 700 lignes de la première table donnent700 lignes à la fin j'ai envie de dire qu'y à correspondance unique entre les champs ce chaque table et donc qu'une seule table aurait suffit; ce qui semble absurde.

Dans certains cas il est judicieux d'avoir une table supplémentaire, l'exemple type est le stockage d'une image ou d'un document xml très volumineux.
La cardinalité dans ce cas au niveau conceptuel est souvent 0,1 mais empiriquement on peut constater du 1,1 ou pas loin

Pour apporter plus d'infos, la base sur laquelle je travaille ne dispose d'aucune clé étrangère entre les tables alors qu'elle est en fonctionnement depuis plusieurs années. J'ai pensé à utiliser une liaison de type NATURAL JOIN, mais les champs n'ont pas les mêmes noms, et dans certains cas, pas le même format (smallint(4) dans une table pour int(6) dans l'autre,....)

Le "natural join" est à fuir comme la peste, si vous modifiez les tables, le résultat de la requête changera, alors qu'une jointure explicite vous met à l'abri de ce genre de mésaventure

Si j'ai bien compris le fonctionnement du INNER JOIN :
- Il ne peut y avoir qu'une seule table dans la clause FROM
- La table dans la clause FROM doit être en lien avec au moins un champ dans la clause SELECT.
- Chaque jointure ajoutée dans un JOIN doit être en lien avec une des jointures précédentes.

Il ne peut effectivement y avoir qu'une seule table ou vue dans la clause FROM, par contre
- il n'est pas nécessaire que des colonnes de la table ou de la vue de la clause FROM soient utilisées dans la clause SELECT
- les jointures des tables en jointure INNER JOIN ou OUTER JOIN peuvent se rapporter à n'importe laquelle des tables ou vues de la clause FROM ou d'une des tables jointes via INNER ou OUTER JOIN

[AurelienG_]

Bonjour à tous.

J'ai profité de ce week-end pour creuser le mode de fonctionnement de la base de données que j'exploite et j'ai fini par comprendre mon problème de 60 000 lignes.
Il s'avère qu'il s'agit d'un biais de conception de la base ou la jointure ne se fait pas de la PK vers la FK, mais d'une FK vers une autre FK (Celle-ci n'étant pas au format InnoDB).
En liant sur le mauvais champ on assistait à une sorte de "produit cartésien" (dites moi si je me trompe) ou la requête affichait tous les résultats possibles.

La seule in connue qui reste dans ton problème se cache dans "Critères de selection " et c'est peut-être là qu'est l'os comme on dit en Grèce !

Le problème ne venait pas de la, en revanche je sais ou axer mes recherches si jamais je rencontre un volume de réponses volumineux.

Donc sans avoir de jeu de test, on ne peux pas savoir ce qui ne va pas dans la requête... mais ce n'est pas (à priori) un problème de jointure.

C'était bien un probleme de jointure, c'était seulment pas le bon champ.

Le "natural join" est à fuir comme la peste, si vous modifiez les tables, le résultat de la requête changera, alors qu'une jointure explicite vous met à l'abri de ce genre de mésaventure

J'ai testé le NATURAL JOIN ce weekend avec une base factice : En effet à fuir, souplesse dans la gestion de la base : 0 ! On change une seul caractère de champ et c'est toute les requêtes qui sont foutues, donc pour l'administration ou pour la maintenance... C'est tout pourri !

- il n'est pas nécessaire que des colonnes de la table ou de la vue de la clause FROM soient utilisées dans la clause SELECT

Oui, c'est ce que j'appelle un "pont", c'est à dire une table qui va seulement servir de lien entre deux autres sans pour autant que l'on fasse appel à son contenu dans la clause SELECT.
En général pour plus de clarté dans des requêtes qui ne nécessitent pas de calcul, je fais en sorte de placer dans le FROM la table qui appelle le plus de champs dans la clause SELECT.

En attendant, merci pour vos réponses, le sujet est résolu Je suis peut être pas un pro de l'INNER JOIN, mais je me soigne

Je laisse le sujet ouvert si jamais des participants veulent compléter en infos (sauf si l'admin en décide autrement )

[Rei Ichido]

Le "natural join" est à fuir comme la peste, si vous modifiez les tables, le résultat de la requête changera, alors qu'une jointure explicite vous met à l'abri de ce genre de mésaventure

Pour moi le pire du Natural Join, c'est qu'on se retrouve vite avec des colonnes qui ont des noms identiques (les plus basiques étant par exemple is_active ou last_update, mais on peut aussi se retrouver avec des colonnes de montant, de nom, etc.). Evidemment si on fait de la jointure dessus, c'est le drame ! Je n'ai compris l'intérêt de cette syntaxe de jointure qui ne m'a jamais apparu ne serait-ce que marginalement utile.