utiliser le JOIN permet de séparer jointures et filtre, c'est agréable et lisible quand il y a beaucoup des unes et beaucoup des autres.

La clause WHERE pour faire des jointures n'est plus recommandée pour les SGBD actuels car moins performante que JOIN.

L'idée de base du SQL et des langages déclaratifs, c'est de permettre au développeur de dire ce qu'il veut obtenir comme résultat sans se préoccuper de savoir comment le SGBD va faire pour atteindre le résultat (contrairement aux langages procéduraux classiques où le développeur décrit la manière d'obtenir le résultat : l'algorithme). Ce serait donc une régression que les développeurs soient maintenant obligés de se dire "il faut que j'utilise JOIN plutôt que WHERE" car le moteur d'optimisation des requêtes du SGBD ne remplit pas son rôle.

Ensuite, mettre dans le même sac tous les SBGD "actuels" qui seraient tous plus performants avec JOIN qu'avec WHERE me semble étrange : chacun d'entre eux a, que je sache, un moteur d'optimisation des requêtes entièrement différent. Il n'y a donc aucune raison que tous les développeurs de SGBD aient décidé, en même temps, de privilégier les JOIN par rapport aux WHERE.
D'autant plus que par exemple, Oracle utilise une syntaxe très spécifique (et à mon avis beaucoup plus lisible, mais ce n'est pas le sujet) qui permet de faire des jointures externes directement dans la clause WHERE.

Enfin, la documentation MySQL n'est pas vraiment explicite sur le gain de performances de JOIN sur WHERE. Au contraire, on y lit à la page Comment MySQL optimise les clauses LEFT JOIN et RIGHT JOIN

Toutes les conditions du LEFT JOIN sont transmises à la clause WHERE.

ou encore

Depuis la version 4.0.14, MySQL effectue l'optimisation LEFT JOIN suivante : si la condition WHERE est toujours fausse pour la ligne NULL générée, la jointure LEFT JOIN est transformée en jointure normale.
Par exemple, dans la requête suivante, la clause WHERE sera fausse si t2.column est NULL : il est donc valide de convertir la jointure en une jointure normale.

Code : Tout sélectionner

SELECT * FROM t1 LEFT JOIN t2 ON (column1) WHERE t2.column2=5;

Par conséquent, il est possible de convertir la requête en jointure normale :

Code : Tout sélectionner

SELECT * FROM t1,t2 WHERE t2.column2=5 AND t1.column1=t2.column1;

Cela peut se faire plus rapidement, car MySQL peut maintenant utiliser la table t2 avant la table t1 si les relations sont plus favorables.

Le truc c'est que conceptuellement une jointure se fait par JOIN. la majorité des sgbd optimisent les conditions du where, et arrivent à des performances comparables pour les deux notations, mais dans ce cas le JOIN ne servirait plus à rien...
Tu dis que l'on n'est pas sensé se préoccuper de comment les sgbd optimisent, mais justement, dans ce cas, on est sensé utiliser le JOIN, qui se veut être l'opérateur de jointure.

Et sinon, quelle que soit la manière, tu avances sur la tienne (de jointure) nebil ?

Le truc c'est que conceptuellement une jointure se fait par JOIN.

Le truc, c'est que les éditeurs de base de données ne disent pas ça. Je viens de vérifier dans la doc Oracle, dans la doc Sybase SQL Server et dans la doc MySQL, tous les exemples donnés mettent les jointures dans la clause WHERE sauf dans le cas des outer joins. Je ne vais pas mettre en doute les compétences des uns et des autres, mais vous me permettrez de préférer suivre les recommandations des éditeurs concernés.

Using Join Queries: Example

Code : Tout sélectionner

SELECT last_name, job_id, departments.department_id, department_name FROM employees, departments WHERE employees.department_id = departments.department_id;

Using Self Joins: Example

Code : Tout sélectionner

SELECT e1.last_name||' works for '||e2.last_name "Employees and Their Managers" FROM employees e1, employees e2 WHERE e1.manager_id = e2.employee_id AND e1.last_name LIKE 'R%';

Using Outer Joins: Example

Code : Tout sélectionner

SELECT d.department_id, e.last_name FROM departments d LEFT OUTER JOIN employees e ON d.department_id = e.department_id ORDER BY d.department_id;

Using Antijoins: Example

Code : Tout sélectionner

SELECT * FROM employees WHERE department_id NOT IN (SELECT department_id FROM departments WHERE location_id = 1700);

Using Semijoins: Example

Code : Tout sélectionner

SELECT * FROM departments WHERE EXISTS (SELECT * FROM employees WHERE departments.department_id = employees.department_id AND employees.salary > 2500);

Maintenant, chacun est libre d'utiliser la manière de programmer les requêtes qui correspond le mieux à sa sensibilité.

Ce ne sont pas les éditeurs de base de données qui font les concepts. Mais le langage est tel qu'il est. Traditionnellement une jointure se fait par JOIN. Pour comparaison, en PHP, tu as bien des boucles while qui te permettent de faire :

while(list($machin,$truc) = each($tab))

Seulement la plupart du temps on privilégie une boucle foreach plus lisible :

foreach($tab as $machin=>$truc)

Pour quelle raison ? Le while est plus performant, mais le foreach plus lisible, il a été créé pour cela, même s'il est techniquement possible de faire autrement. Donc les éditeurs de SGBD n'ont pas tort d'écrire les jointures de cette manière, puisque c'est valide, c'est peut être par défaut plus performant (même si JOIN permet de guider l'optimiseur et de lui éviter de se tromper), et puis c'est l'occasion de montrer la puissance des optimisations du SGBD, de montrer que les clauses WHERE sont aussi efficaces que les JOIN. Mais ce n'est pas juste conceptuellement, parce que JOIN est l'opération conçue pour la jointure, alors que le produit cartésien est censé être réservé à l'établissement de tous les couples d'enregistrement (table1, table2).

hm, si je peux me permettre...
NON
on ne fait pas de jointure sur une clause WHERE! scrogneugneu
une jointure c'est

Code : Tout sélectionner

SELECT ... FROM table1 AS t1 LEFT JOIN table2 AS t2 ON (t1.champ1 = t2.champ2) WHERE ...

Vous me copierez 100 fois "je ne ferai plus de jointure sur une clause WHERE"
non mais oh

C'est vrai ... honte à moi
C'est juste que c'est plus simple à comprendre pour quelqu'un qui ne connait pas ...