Discussion :

[clavier12AZQSWX]

bonjour,

avec Postgresql, est-il vrai qu'une jointure par LEFT JOIN est plus rapide qu'une jointure par produit cartesien ou bien est-ce juste une histoire de normalisation dans le code SQL ?

par l'exemple , qu'est-ce qui est plus rapide :
solution a:

Code :

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

SELECT table1.monchamp FROM table1,table2 WHERE table1.cleetrangere=table2.id

solution b :

Code :

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

SELECT table1.monchamp FROM table1 LEFT JOINT table2 ON table1.cleetrangere=table2.id

Est-ce vrai dans 100% des cas ou bien ça dépend de certaines choses ?
quelqu'un a-t-il une idée du facteur de rapidité si c'est différent en vitesse ?

merci à vous

[alassanediakite]

Salut
Tout d'abord le titre doit être revu!
Pour la question...

1. LEFT JOIN n'est pas WHERE t1.cle=t2.cleetrangere. Il faut d'autres critères dans le WHERE!
2. INNER JOIN est identique à t1.cle=t2.cleetrangere; pour PostgreSQL et tout SGBDR intelligent.

@+

[sevyc64]

Question intéressante s'il en est car personnellement je ne me la serais pas posé, persuadé, à tort probablement, que le moteur SQL traduisait les 2 requêtes en un plan d’exécution identique.

Même remarque que alassanediakite, le produit cartésien tel qu'écrit ici est l'équivalent d'une INNER JOIN pas d'un LEFT JOIN.

Remarque que je rajoute à l'occasion, parce qu'on le vois aussi trop souvent : Attention aux filtres dans le WHERE sur la seconde table d'une LEFT JOIN qui, si on n'y fait pas bien attention, transforme implicitement une LEFT JOIN en INNER JOIN

[clavier12AZQSWX]

j'ai fait un test avec une table1 de 10000 tuples et une table2 de 5000 et je n'ai pas vu différence sur une vielle machine serveur.

donc, dois-je onclure que soluation a = solution b en terme de rapidité ?

[SQLpro]

Sur tout SGBD Relationnel intelligent, le plan d'exécution doit effectivement être le même. Cependant, le calcul dudit plan nécessite plus de travail pour l'algébriseur/optimiseur car le prédicat de jointure est noyé parmi les opérations de restriction. Il faut alors généralement deux passes dans l'arbre algébrique : l'une pour remonter les restrictions en jointures, l'autre pour définir les véritables restriction, sachant que logiquement, les jointures s'effectuent avant les restrictions.

Donc, l'écriture de jointure dans la clause WHERE pénalise le moteur, mais pas spécialement l'exécution de la requête !

En tout état de cause, c'est une grande stupidité que de ne pas utiliser le JOIN (opérateur de jointure) pour faire des jointures !

A +

[sevyc64]

En tout état de cause, c'est une grande stupidité que de ne pas utiliser le JOIN (opérateur de jointure) pour faire des jointures !

Et c'est une grande stupidité que de l'enseigner mais c'est pourtant toujours le cas

[SQLpro]

Tu sais bien que ça fait longtemps que je tape sur les profs qui continuent d'enseigner cette ignominie !!!!

A +

[ok.Idriss]

Tu sais bien que ça fait longtemps que je tape sur les profs qui continuent d'enseigner cette ignominie !

Ça doit être fatiguant à la longue car il me semble qu'ils sont encore très nombreux

Notamment, je me souviens que ça faisait partie du référentiel national d’examen de la formation du BTS IG autrefois (qui n'existe plus), alors que ça faisait bien 15 ans que 1992 était passé ... et ça n'est qu'un exemple parmi d'autres.

J'avais eu la chance d'avoir une enseignante nous ayant montré les deux syntaxes tout en indiquant que l'une d'elle est plus récente et préférable mais nous recommandant d'utiliser la vielle syntaxe du WHERE dans l'examen car beaucoup de correcteurs ne sont pas à la page

Idriss