Discussion :

[ymoreau]

Bonjour,
J'ai besoin d'associer des informations de 2 tables, mais qui ne sont pas liées directement. Chacune de ces tables a sa clé primaire associée en clé étrangère dans deux autres tables qui elles même sont associées entre elles par l'une d'elle ayant une clé étrangère sur l'autre.

Plus concrètement voici les tables :
unite et espece (dont je souhaite récupérer des infos)
parcelle (ayant une clé étrangère vers unite)
culture (ayant une clé étrangère vers parcelle et espece)

Voilà la requête que je veux faire

Code :

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

1
2
SELECT DISTINCT unite.nom AS nom_unite, espece.nom AS nom_espece 
FROM (culture JOIN NATURAL espece) JOIN NATURAL (parcelle JOIN NATURAL unite)

J'imagine que le SGBD (PostgreSQL) procédera à des optimisations, mais j'ai peur que la jointure entre autant de tables ne soit vraiment lourde alors qu'au final je n'ai besoin que des attributs des tables unite et espece. Est-ce que lors de la jointure tous les attributs de chaque tables seront joints malgré tout ? Je n'ai besoin que des clés étrangères pour faire le lien.

Y'a-t-il une meilleure méthode pour faire cela, des points à optimiser ?
Merci d'avance.

[CinePhil]

Essaie plutôt comme ça (en SQL normalisé) en adaptant le nom de tes clés :

Code :

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

1
2
3
4
5
SELECT DISTINCT u.nom AS unite, e.nom AS espece
FROM culture AS c
INNER JOIN espece AS e ON c.id_espece = e.id_espece
INNER JOIN parcelle AS p ON c.id_parcelle = p.id_parcelle
  INNER JOIN unite AS u ON p.id_unite = u.id_unite

[ymoreau]

Il y a une différence entre les deux ? Sachant que normalement toutes les clés étrangères sont bonnes, je devrais récupérer toutes les lignes de chaque table. Le résultat est donc le même qu'en jointure naturelle je me trompe ?

C'est au niveau de l'exécution que la jointure interne sera plus efficace ?

Edit : en fait ma requête ne renvoyait aucun résultat, alors que ta version me renvoie bien quelque chose, je n'ai probablement pas bien saisi la différence entre les deux jointures.

[CinePhil]

La différence, c'est qu'en jointure naturelle, le SGBD va chercher toutes les colonnes qui portent le même nom dans les deux tables. Et comme je vois que 'nom' est présent dans les tables 'unite' et 'espece', peut-être qu'il y a d'autres homonymes gênant la condition de jointure.

De manière générale, il vaut mieux dire clairement au SGBD sur quoi porte la jointure, ça évite les problèmes.

[ymoreau]

En effet je n'y avais pas pensé, ça explique pourquoi je n'obtenais aucun résultat, comme les noms étaient différents la jointure renvoyait un ensemble vide.

Merci.

En ce qui concerne les performances, l'optimiseur va simplifier la jointure selon les attributs que j'utilise ? (sous entendu ne pas créer une table temporaire contenant toutes les valeurs de toutes mes tables jointes)

Si jamais je souhaite appliquer des conditions disons sur la sélection des cultures, est-ce qu'avec un WHERE le SGBD ne risque pas de faire la jointure totale en premier puis de filtrer les résultats ?
Je sais que ça n'est pas conseillé niveau "sens", mais au niveau performances est-ce que le SGBD saura automatiquement faire l'opération plutôt dans cet ordre :

Code :

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

1
2
3
4
5
SELECT DISTINCT u.nom AS unite, e.nom AS espece
FROM (SELECT * FROM culture WHERE --conditions--) AS c
INNER JOIN espece AS e ON c.id_espece = e.id_espece
INNER JOIN parcelle AS p ON c.id_parcelle = p.id_parcelle
  INNER JOIN unite AS u ON p.id_unite = u.id_unite

Plutôt que dans cet ordre :

Code :

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

1
2
3
4
5
6
SELECT DISTINCT u.nom AS unite, e.nom AS espece
FROM culture AS c
INNER JOIN espece AS e ON c.id_espece = e.id_espece
INNER JOIN parcelle AS p ON c.id_parcelle = p.id_parcelle
  INNER JOIN unite AS u ON p.id_unite = u.id_unite
WHERE --conditions--

[al1_24]

Je ne connais pas suffisamment PostgreSQL pour te répondre. Chaque SGBD a ses propres manières d'optimiser l'exécution des requête.
Le meilleur moyen de les connaître, c'est de consulter le plan d'exécution de la requête et de comparer les résultats des différentes manières de regrouper les conditions...

[pacmann]

Salut !

Je ne connais pas non plus Postgres.
Mais il parait que c'est un vrai SGBD... donc il devrait faire le bon choix !

Hypothèse grossière de fonctionnement de l'optimiseur :
A priori, dans ton modèle "jointure", il va considérer chaque table et les prédicats filtrant associés (qu'on différencie donc des prédicats de jointure).

En fonction des statistiques qu'il a sur ces tables et sur les colonnes de ces tables, il va pouvoir estimer le nombre de lignes renvoyées.

Si la table Culture avec le filtre associé renvoie le moins de ligne, il est assez probable qu'elle soit choisie comme driving table (euh, je crois qu'on dit pivot ?) pour commencer à faire les jointures. Dans ce cas, aucun doute : il va bien appliquer le filtre AVANT de réaliser les jointures.
(Attention, un optimiseur, c'est vachement plus compliqué que ça en vrai...)

Par ailleurs, lorsque tu utilises une "table dérivée" (ce que tu mets entre parenthèses dans le from), il est fort probable qu'il transforme la requête dans la seconde version... (c'est du moins ce que fait Oracle).

PS : Tu as utilisé des balises QUOTE que tu as déguisé en code ?
(Il y a la balise CODE qui permet d'avoir la coloration syntaxique...)

[ymoreau]

Oui je me doutais que ça allait dépendre du SGBD. J'ai bien mis des balises code, mais l'utilisation du gras et italique a l'air de faire foirer la coloration ^^

Merci de vos réponses, je pense que je vais faire confiance à l'optimiseur pour le moment.