jointure a realiser

par **Vurtu** » 18 juil. 2008, 10:59

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 ...

par **Sékiltoyai** » 17 juil. 2008, 18:00

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).

par **caroube** » 17 juil. 2008, 17:43

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é.

par **ouckileou** » 17 juil. 2008, 14:08

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

par **Sékiltoyai** » 17 juil. 2008, 13:11

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.

par **caroube** » 17 juil. 2008, 10:51

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.

par **ouckileou** » 17 juil. 2008, 09:19

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.

par **Sékiltoyai** » 17 juil. 2008, 01:23

Le seul truc qui me gène c'est que les optimisations basiques sont mal documentées. Et on a tout de même du mal à voir à quel point un JOIN ON sera plus intéressant qu'un FROM WHERE…

par AB » 16 juil. 2008, 22:51

En fait il est préférable de faire les jointures par JOIN pour aider le SGBD à optimiser la requète…

Oui c'est le même argument qu'on peut lire sur developper.com ou ailleurs (sur le manuel mysql par exemple). La clause WHERE pour faire des jointures n'est plus recommandée pour les SGBD actuels car moins performante que JOIN.

Maintenant d'accord avec Zeus et Caroube pour ne pas avancer des opinions à l'emporte pièce, mais dans ce cas, il semble qu'il faille préférer le JOIN si l'on se réfère à la doc

par **zeus** » 16 juil. 2008, 20:22

Je suis d'accord avec caroube et Sekiltoyai.

Non seulement, il ne faut pas avancer des éléments si on est pas sûr de ça. Car, effectivement, ce n'est pas forcément une mauvaise pratique de développement.
Mais, comme le souligne Sekiltoyai, dans le cas de MySQL, le JOIN est un bon moyen de controler l'exécution des requêtes

par **Sékiltoyai** » 16 juil. 2008, 19:47

En fait il est préférable de faire les jointures par JOIN pour aider le SGBD à optimiser la requète…

par **caroube** » 16 juil. 2008, 19:30

C'est quoi ces opinions à l'emporte pièce ?
Bien sûr que si, on fait des jointures dans les clauses where : il suffit de prendre n'importe quel cours SQL pour s'en rendre compte : le produit cartésien est d'ailleurs l'une des bases fondamentales de SQL.

Il n'y a effectivement que si des éléments de la table jointe peuvent ne pas exister que l'on utilise la syntaxe LEFT JOIN, ce qui dans l'exemple présent est probablement le cas;

par **Shrell** » 16 juil. 2008, 11:26

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

par **Vurtu** » 15 juil. 2008, 15:10

Il fallait commencer par là

Pour réaliser une jointure, de base, il suffit d'introduire dans ta requete une condition dite "de jointure" reliant les champs des deux tables ayant un rapport. Dans ton cas, le champ id de la table automobiles et le champ id_auto de la table options

Le code est :

Code : Tout sélectionner

SELECT [...] FROM automobile as a, options as o WHERE a.id=o.auto_id

Il te suffit ensuite d'y insérer le reste de tes conditions.

PS : je suis sûr qu'avec un minimum de recherche dans le forum ou sur google, tu aurais trouvé la solution sans soucis

par **nebil** » 15 juil. 2008, 15:03

non je ne sais pas relier les tables
enfin j'ai une vague idée , mais mon probleme c'est que je n'arrive pas a comprendre tout les termes technique du coup parfois meme les tuto m'aide pas beaucoup
je crois comprendre
que cela peut ce faire de cette maniere

select * automobile join options where (......)
ou
select *automobile where (........) join option where (.....)

jointure a realiser

Répondre

Étendre la vue Revue du sujet : jointure a realiser