Salut à tous,

La question est dans le titre : faut-il utiliser les jointures du genre
1)
"
SELECT champs
FROM Table
WHERE Table.colonne = Autretable.autrecolonne"

ou plutôt

2)"SELECT champs
FROM Table
JOIN Autretable
ON Table.colonne = Autretable.autrecolonne"

Qu'est ce qui est le mieux niveau optimisation ? J'ai plus tendance à utiliser le WHERE...

Avis ?

le premier ca ne devrait juste pas marcher.

le deuxieme est equivalent a
"SELECT champs FROM Table, Autretable ON Table.colonne = Autretable.autrecolonne"

Cote optimisation, c'est un un cauchemard de predire quelle commande fait quoi. Il faut analyser la sortie du planificateur de ton SGBD.

SI, la première forme marche.

Pour reprendre l'exemple du tuto de developpez.com :

"
SELECT C.CLI_ID, C.CLI_NOM, T.TEL_NUMERO
FROM T_CLIENT C, T_TELEPHONE T
WHERE C.CLI_ID = T.CLI_ID
AND T.TYP_CODE = 'FAX'
"
(cf. : http://sqlpro.developpez.pez.com/cours/sqlaz/jointures/ )

Visiblement, ils recommandent l'utilisation de JOIN.
Pourtant en cours on a toujours utilisé la syntaxe avec la clause WHERE et les égalités...

dans le deuxieme exemple que tu donnes, tu as bien deux table dans le champ FROM ce qui n'etait pas le cas dans ton premier exemple.

La difference entre utiliser JOIN et WHERE est purement syntaxique il me semble. Il y avait un bug de performance dans les serveurs oracle en 2006 il me semble sur ce point la en particulier, mais maintenant ils donnent le meme plan d'execution.

Encore une fois, ce qui est important, ce sont les statistiques de tes tables et ce que le plannificateur choisi. Regardes la tete du plan et vois si ca fait bien ce que tu veux.

Je n'utilise que MySQL (via l'interface PHPMyAdmin pour l'instant).
Qu'entends-tu par statistique des tables ? Ma BDD acvtuelle n'est pas très grosse, la table comprenant le +d'enregistrepent doit faire 30 lignes...
De même, où se trouve le planificateur ?

godrik : c'est pas plutôt laisser à la discrétion des concepteurs de SGBD ces choses là ?

Il te parle des outils d'audit de requêtes, dont la nature et la qualité change suivant les Sgbd. Et contrairement à la pensée populaire, Mysql est loin d'être un champion.

Sinon pour ta demande, les 2 syntaxes sont équivalentes et optimisées de façon identique sauf cas tordu.

Cependant la condition dans le WHERE correspond à un INNER JOIN et c'est pas possible de faire un RIGHT ou un LEFT JOIN sans passer par l'aitre syntaxe.

Perso, pour des raisons de lisibilité, j'utilise toujours les syntaxes "(LEFT|INNER)JOIN table ON ()" afin de bien séparer les critères de jointures des conditions.
Sans cela, sitôt que tu as 3 tables jointes et 2-3 critères "WHERE", cela devient moins agréable à la relecture.

chris, ce que je veux dire est qu'il me semble que l'arbre d'evaluation relationnel (or whatever its actual name is) des deux requetes devraient etre equivalent. Donc la question est comment le SGBD considere chacune des requetes. Si il part sur deux representatoin initial differente des requete et qu'il applique un heuristique bizarre (je ne connais pas trop les details interne tordu des SGBD) il pourrait arriver a deux plan d'operation different. Mais en pratique dans un cas d'utilisation classique, les deux requetes devraient avoir le meme plan d'execution parcequ'elles sont tres simple (donc j'imagine que les heuristiques vont converger).

"Qu'entends-tu par statistique des tables ? Ma BDD acvtuelle n'est pas très grosse, la table comprenant le +d'enregistrepent doit faire 30 lignes..."

donc probablement ts ne constatera aucun probleme de performance.

"De même, où se trouve le planificateur ?"

lire ceci pourrait etre interessant: http://dev.mysql.com/doc/refman/5.5/en/execution-plan-information.html

Cependant, si tu commences en base de donnees, les problemes de modelisatoin sont plus important que les problemes d'optimisation.