Question générale : liens entre tables d'une BDD et jointures SQL

Bonjour à tous,

Je pense que je vais me faire passer pour un charlot avec ma question.
Mais je tente... quand même... :)

Question générale juste pour comprendre le mécanisme de fonctionnement.

En gros, j'ai une BDD Access faite d'une table principale et de tables satellites avec des liens (plusieurs - un) avec la table principale.
Je fais une requête SQL simple dessus avec un WHERE TablePrincipale.ChampX = TableSatellite.ChampY AND TableSatellite.ChampY='Valeur'

Pourquoi faut-il préciser dans le WHERE le lien de la TablePrincipale avec la TableSatellite (TablePrincipale.ChampX = TableSatellite.ChampY) ?
C'est pas implicite pour lui ? J'ai déjà créé mes liens entre les tables dans Access. C'est déjà dans ma base de données. La requête ne prend pas en compte les liens créés entre les tables ? Il faut tout lui repréciser ?

Je ne comprends pas cela...

Merci de votre aide.

Je ne connais pas Access, mais je dirais :

Soit parce que tu as dans tes 2 tables des colonnes du même nom, préciser la table permet ainsi de lever tout ambiguïté

Soit parce que Access a toujours besoin de qualifier pleinement la colonne

Bonjour,

Alors normalement les jointures se précisent dans la clause JOIN. La clause WHERE sert à filtrer les données une fois jointes. C'est conceptuellement plus facile à comprendre comme ça.
Maintenant pour répondre à ta question, pourquoi les jointures ne se font pas toutes seules. Premièrement, pour des raisons évidentes de clarté. Sans les jointures, il faudrait rechercher la déclaration des tables pour voir quelles sont les clés primaires et étrangères définies. Pas évident si ta requête implique une dizaine de tables par exemple. Ensuite, rien ne garantit que les liens entre les différentes tables aient été faits correctement. Enfin, tu peux très bien vouloir faire une jointure sans forcément associer toutes les colonnes des clés définies.

Bonsoir Vanagreg,

Donc si je comprends bien, il faut lui indiquer les jointures et je comprends mieux pourquoi maintenant.

Si je mets les jointures dans un WHERE tout simple, ça fonctionne bien. Je l'ai testé.
Mais si je te suis, c'est pas très propre comme écriture de code. C'est cela ?

Du coup, si je veux être plus rigoureux dans le code (ce que je souhaite), je dois faire des inner join pour chaque jointure et mettre les valeurs filtres dans le WHERE ?
C'est plus propre comme codage ?

Et en terme de temps d'exécution de requête, c'est la même chose ?
Car j'ai cru lire en me documentant qu'il faisait d'abord une projection complète avec les INNER JOIN puis appliquait les filtres dessus.

En tout cas, merci car on apprend beaucoup ici.

Les performances peuvent être meilleurs avec JOIN :

Avec certains optimiseurs, faire la jointure dans la restriction (dans le WHERE) pénalise les performances, car la restriction est appliquée après avoir fait le produit cartésien, alors que la clause JOIN permet de faire d'abord la jointure puis la restriction.
Cela étant dit, le plus souvent, ça ne change rien aux performances, mais il est plus clair de séparer ce qui est du ressort de la jointure de ce qui est du ressort de la restriction, ce sont bien deux notions fonctionnellement très différentes.

Citation:

---

Envoyé par Krys9292

Bonjour à tous,

Je pense que je vais me faire passer pour un charlot avec ma question.
Mais je tente... quand même... :)

Question générale juste pour comprendre le mécanisme de fonctionnement.

En gros, j'ai une BDD Access faite d'une table principale et de tables satellites avec des liens (plusieurs - un) avec la table principale.

---

La notion de "line" n'existe pas dans l'univers des bases de données relationnelles. C'est même le contraire, c'est l'absence de lien qui permet aux SGBD Relationnel d'être bien supérieur à tout autre systèmes de SGBD... Ce que vous appelez lien est sans doute une clef étrangère, gérée par une intégrité référentielle (contraintes) pour éviter que des lignes d'une table fille référençant une table mère ne deviennet orphelines de la référence.

Un exemple simple avec CLIENT et FACTURE.

Un facture sans client c'est inconcevable. Il faut donc référencer le client afférent à une facture. Voici comment l'on s'y prend en SQL :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

CREATE TABLE T_CLIENT_CLI (CLI_ID INT PRIMARY KEY, CLI_NOM VARCHAR(32), CLI_CREATION DATE);   CREATE TABLE T_FACTURE_FAC (FAC_ID INT PRIMARY KEY, CLI_ID INT FOREIGN KEY REFERENCES T_CLIENT_CLI (CLI_ID), --> les valeurs de ,cette information doivent être prise dans la table des clients FAC_DATE DATE, FAC_MONTANT DECIMAL(16,2), FAC_LIBELLE VARCHAR(256));

---

Ainsi il ne sera pas possible de supprimer un client ayant des factures...

Quant à la jointure c'est une opération de rapprochement de données basées sur n'importe quelle colonnes d'au moins deux tables...

Voici trois exemples de jointures :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

-- les factures émise après la création du client n°999 SELECT F.* FROM T_FACTURE_FAC AS F JOIN T_CLIENT_CLI AS C ON FAC_DATE > CLI_CREATION WHERE F.CLI_ID = 999;   -- les factures dont le libellé contient un nom de client SELECT F.* FROM T_FACTURE_FAC AS F JOIN T_CLIENT_CLI AS C ON FAC_LIBELLE LIKE CONCAT('%', CLI_NOM, '%');   -- les factures du client 133 SELECT F.* FROM T_FACTURE_FAC AS F JOIN T_CLIENT_CLI AS C ON F.CLI_ID = C.CLI_ID WHERE C.CLI_ID = 133;

---

Comme vous le constatez une seule des 3 requêtes base sa jointure sur la clef étrangère en rapport à la clé primaire de référence...

Autrement dit, une jointure n'a pas de "line génétique" avec l'intégrité référentielle ! Et heureusement....
Autrefois dans les based e donnés en Cobol c'était le cas et on était très limité pour l'interrogation des données.... (années 50 à 70 c'est à dire avant l'arrivée des SGBD Relationnels.)

Citation:

---

Je fais une requête SQL simple dessus avec un WHERE TablePrincipale.ChampX = TableSatellite.ChampY AND TableSatellite.ChampY='Valeur'

Pourquoi faut-il préciser dans le WHERE le lien de la TablePrincipale avec la TableSatellite (TablePrincipale.ChampX = TableSatellite.ChampY) ?
C'est pas implicite pour lui ? J'ai déjà créé mes liens entre les tables dans Access. C'est déjà dans ma base de données. La requête ne prend pas en compte les liens créés entre les tables ? Il faut tout lui repréciser ?

---

Enfin les jointure ne doivent pas se faire ans le WHERE. Je m'étonne encore que l'on apprenne cette imbécilité !

A +

PS lisez mon cours sur le SQL et notamment : https://sqlpro.developpez.com/cours/...ointures/#LIII

Je te remercie SQLpro pour avoir pris ton temps pour m'expliquer tout cela.
Je l'ai relu plusieurs fois pour bien tout saisir.

Effectivement, je n'allais pas dans le bon sens. Je n'avais pas saisi la philosophie du truc.
En plus tes codes m'ont donné des idées sur les possibilités du coup très vastes.

Quant au WHERE... c'est vrai que c'est dommage de retrouver cela sur certains tutos.
Car en fait, ça oriente mal les gens comme moi qui apprennent, à d'une part ne pas pouvoir comprendre les concepts qui se cachent derrière (c'est important), d'autre part à adopter des mauvaises pratiques de développement, et au final à adopter le comportement de je ne comprends rien de ce que j'écris mais du moment que "ça marche"...

En tout cas, merci encore. :)

Du coup, je me suis documenté sur ces sujets.
Et j'ai même repéré avec tes explications certains tutos vraiment pas "propres".

Depuis, j'ai réussi à enchâsser plusieurs INNER JOIN les uns sur les autres. Et ça marche bien. Et effectivement, c'est rapide.

Juste que je sèche maintenant sur un problème. J'ai une table qui est jointe plusieurs fois à différents champs de ma table principale mais qui prend des valeurs différentes.
Du coup, quand j'écris les INNER JOIN les uns sur les autres, il ne comprend plus.
J'imagine qu'il doit se dire, j'ai une relation entre la petite table et la table principale, puis une autre entre cette même petite table et la table principale mais la relation différente... Et il comprend plus, ça le bloque car pour lui c'es incompatible...
Je ne sais pas, mais avec mes recherches, j'avais juste une idée. Faire deux requêtes séparées et les associer... Je ne sais pas si c'est possible de faire par exemple un SELECT sur deux SELECT

Quand on a besoin d'utiliser plusieurs fois la même table dans une requête, il suffit de lui donner des noms différents en utilisant des alias de tables comme ci-dessous :

Code:

---

1 2 3 4 5 6 7 8 9

select T1A.Col1 , T1A.Col2 , T1B.Colx , T1B.Coly From table1 as T1A inner join table1 as T1B on T1B.Col1=T1A.Col1 and T1B.Colz>T1A.Colz where ...

---

Citation:

---

Envoyé par Krys9292

...
Juste que je sèche maintenant sur un problème. J'ai une table qui est jointe plusieurs fois à différents champs de ma table principale mais qui prend des valeurs différentes.
Du coup, quand j'écris les INNER JOIN les uns sur les autres, il ne comprend plus.
J'imagine qu'il doit se dire, j'ai une relation entre la petite table et la table principale, puis une autre entre cette même petite table et la table principale mais la relation différente... Et il comprend plus, ça le bloque car pour lui c'es incompatible...
Je ne sais pas, mais avec mes recherches, j'avais juste une idée. Faire deux requêtes séparées et les associer... Je ne sais pas si c'est possible de faire par exemple un SELECT sur deux SELECT

---

En fait, la plupart du temps, quand apparait plusieurs fois la même table, ce n'est pas forcément pour avoir les mêmes lignes que la jointure doit se faire. Il faudra dédoubler les version de cette table en ajoutant un alias afin de distinguer les lignes de l'une avec les lignes de l'autre... Un petit exemple

Soit les tables suivantes :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

CREATE TABLE T_PERSONNE_PRS (PRS_ID INT PRIMARY KEY, PRS_NOM VARCHAR(32), PRS_PRENOM VARCHAR(25), PRS_D_NAISSANCE DATE, PRS_SEXE CHAR(5) CHECK(PRS_SEXE IN ('Homme', 'Femme')));   CREATE TABLE T_MARIAGE_MRG (MRG_ID INT PRIMARY KEY, MRG_DATE DATE, MRG_LIEU VARCHAR(128), MRG_CONJOINT1 INT REFERENCES T_PERSONNE_PRS (PRS_ID), MRG_CONJOINT2 INT REFERENCES T_PERSONNE_PRS (PRS_ID))

---

Et les données des personnes comme ci après :

Code:

---

1 2 3 4 5

INSERT INTO T_PERSONNE_PRS VALUES (1, 'Martin', 'Martine', '2000-05-15', 'Femme'), (2, 'Dupont', 'Philippe', '1999-08-17', 'Homme'), (3, 'Schmidt', 'Adolphe', '1940-11-21', 'Homme'), (4, 'Lebrun', 'Victoire', '1944-06-06', 'Femme');

---

La question simple est : pouvons nous marier une personne avec elle même ?
Et la réponse évidente est NON !

Voici un exemple d'insertion dans la table des mariages :

Code:

---

1 2	INSERT INTO T_MARIAGE_MRG VALUES (999, '2023-03-15', 'Singapour', 1, 2);

---

Il va donc y avoir dans la table de mariage, deux fois des références à une personne, mais ce ne seront jamais les mêmes personnes.
D’où l’obligation, dans la requête, de faire figurer deux fois la table, avec deux alias différent afin de lire des lignes dissociées !

Pour retrouver qui s'est marié avec qui voici la solution avec des alias pour toutes les tables :

Code:

---

1 2 3 4 5 6

SELECT MRG_DATE, MRG_LIEU, CONCAT(P1.PRS_PRENOM, ' ', P1.PRS_NOM, ' (', P1.PRS_SEXE, ')') AS CONJOINT1, CONCAT(P2.PRS_PRENOM, ' ', P2.PRS_NOM, ' (', P2.PRS_SEXE, ')') AS CONJOINT2 FROM T_MARIAGE_MRG AS M JOIN T_PERSONNE_PRS AS P1 ON M.MRG_CONJOINT1 = P1.PRS_ID JOIN T_PERSONNE_PRS AS P2 ON M.MRG_CONJOINT2 = P2.PRS_ID;

---

Et le résultat :

Code:

---

1 2 3

MRG_DATE MRG_LIEU CONJOINT1 CONJOINT2 ---------- ------------- ----------------------- ------------------------ 2023-03-15 Singapour Martine Martin (Femme) Philippe Dupont (Homme)

---

Le mieux étant re renforcer la table des mariage par une contraintes excluant que l'on se marie avec soi même :

Code:

---

1 2	ALTER TABLE T_MARIAGE_MRG ADD CHECK(MRG_CONJOINT1 <> MRG_CONJOINT2);

---

Pour information tout ceci était bien précisé dans mon cours, à la même page :
https://sqlpro.developpez.com/cours/...intures/#LIV-C


A +

Bonjour à tous,

Avec vos explications, j'ai trouvé une solution qui fonctionne bien :

je fais des LEFT OUTER JOIN les uns sur les autres en renommant (AS) le résultat (SELECT) à chaque fois pour que les bons champs soient pris en compte.
Je finis par un simple SELECT en fonction de ce que je veux au final (champs, filtrage, tri).

Merci à tous.