Discussion :

[mealtone]

slt,
je souhaiterai appliquer deux jointures, j'ai une table "prestation" a laquelle j'ai affecté deux attributs "idville" et "idtype", chacun d'eux étant respectivement l'attribut de la table ville et type.
Voici la requete sur une première jointure:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
$query = "SELECT 
PRIX,
REFERENCE,
type_prestation,
idtype,
NBPIECE,
NOMVILLE,
NOMTYPE
FROM prestation JOIN ville using(IDVILLE) AND JOIN type using(IDTYPE)
WHERE 1 ";

j'ai affecté une deuxieme jointure, le code est faux mais c'est pour montrer ce que j'attend
merci

[gisele]

Salut Mealtonne,

pas de AND entre les JOIN.
Ta requete doit refleter la relation entre les tables.


ville(1 <= IDVILLE => n) prestation (n <= IDTYPE => 1) type

Elle doit «*traverser*» les tables, les enfiler comme des perles, d'un seul trait, de droite à gauche ou de gauche a droites, les champs de la jointures constituent les maillons de la chaine.

Donc comme tu le vois si tu attaque ta requete avec la table prestation, tu ne peut pas enchainer les tables.

Prends toujours une table a l'extrémitée de la chaine relationnelle (ici soit ville, soit type).
Par exemple ta requete commence par ville puis traverse prestation puis type.

Code :

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

1
2
3
4
 
$query = "SELECT PRIX, REFERENCE,type_prestation, idtype, NBPIECE, NOMVILLE, NOMTYPE
FROM ville JOIN prestation using(IDVILLE) JOIN type using(IDTYPE)
WHERE 1 ";

[Feeder_Fan]

Il vaut mieux faire le produit cartésien des tables et ensuite faire des séléctions, c'est plus académique (certains diront non) mais je trouve ca plus lisible.

Code :

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

1
2
3
4
 
SELECT PRIX, REFERENCE, type_prestation, idtype, NBPIECE, NOMVILLE, NOMTYPE
FROM prestation p, ville v, type t
WHERE p.IDVILLE = v.IDVILLE AND p.IDTYPE = t.IDTYPE ;

[gisele]

Plus académique ou plus ancien?

pourquoi "il vaut mieux" et sur quels arguments?

Pourquoi autant d'attachement au SQL92 alors que le SQL99 est quand même plus puissant ?

quand la lisibilité, c'est un peu passé en force, au premier abord, l'emploi d'un opérateur de jointure normalisé permet de distinguer ce qui relève de la jointure et ce qui relève d'une simple filtarge de plus je n'ai pas eu a surcharger ma requete d'alias.

pour moi entre :

Code :

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

1
2
3
4
 
SELECT PRIX, REFERENCE, type_prestation, idtype, NBPIECE, NOMVILLE, NOMTYPE
FROM prestation p, ville v, type t
WHERE p.IDVILLE = v.IDVILLE AND p.IDTYPE = t.IDTYPE

et

Code :

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

1
2
3
 
SELECT PRIX, REFERENCE,type_prestation, idtype, NBPIECE, NOMVILLE, NOMTYPE
FROM ville JOIN prestation using(IDVILLE) JOIN type using(IDTYPE)

pour ce qui est du côté explicite de la jointure y a pas photo.

[Feeder_Fan]

C'est pour cela que j'ai dis, je cite "certains diront non".

Même s'il est clair que la normalisation SQL2 est préconisée, si le développeur en l'occurence mealtone patauge un peut, il serait bon de commencer par les bases, à savoir les jointures à "l'ancienne" (Tout simplement pour bien comprendre quel en est le mécanisme).
Et cela même si en algèbre relationnel, la jointure ressemble plus au join de SQL2. Et puis de toute facon niveau optimisation, le temps de la requete est identique, il est quand même mieux de maitriser les deux concepts que de finir idiot.

[Luc Orient]

...
Même s'il est clair que la normalisation SQL2 est préconisée, si le développeur en l'occurence mealtone patauge un peut, il serait bon de commencer par les bases, à savoir les jointures à "l'ancienne" (Tout simplement pour bien comprendre quel en est le mécanisme).

Franchement c'est un détail syntaxique ... Au bout du compte les mécanismes d'accès mis en oeuvre par le SGBD sont les mêmes ...

...Et puis de toute facon niveau optimisation, le temps de la requete est identique, il est quand même mieux de maitriser les deux concepts que de finir idiot.

+1

Je défie quiconque de me faire une requete UPDATE multi-tables avec une jointure a l'ancienne (clause where).

Et comment faites vous des UPDATE multi-tables ?


Bon, je sens que tout cela va partir en troll ...

[Luc Orient]

Il vaut mieux faire le produit cartésien des tables et ensuite faire des séléctions, c'est plus académique (certains diront non) mais je trouve ca plus lisible.

Ah ! Un produit cartésien mais quelle horreur !

La solution proposée ci-après est bien une jointure au sens SQL mais les prédicats de jointure sont exprimés avec la syntaxe du WHERE et non du JOIN.

Code :

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

1
2
3
4
 
SELECT PRIX, REFERENCE, type_prestation, idtype, NBPIECE, NOMVILLE, NOMTYPE
FROM prestation p, ville v, type t
WHERE p.IDVILLE = v.IDVILLE AND p.IDTYPE = t.IDTYPE ;

cf. aussi ce débat :
http://www.developpez.net/forums/sho...d.php?t=195378

[gisele]

Salut,

ben moi j'ai pas attendu le débat, c'est un combat constant, j'ai mal au ventre quand je vois des dévoppeurs qui s'efforcent de faire des requetes au gout du jours et qu'en guise d'expertise on leur conseille de revenir vers une technique plus archaique, en plus en disant 'il vaut mieux" ou encore "c'est plus académique".

Je case JOIN a chaque fois que je peux pour faire évoluer les pratiques, dans cette intervention parmi d'autres, j'essaye d'expliquer les finesses suplémentaires. apportés par cette technique (post #8).
http://www.developpez.net/forums/sho...d.php?t=191918

Je défie quiconque de me faire une requete UPDATE multi-tables avec une jointure a l'ancienne (clause where).

(sans tricher avec les sous-requêtes bien sur :-) )

[gisele]

Salut Feeder,
pas d'accord, le passage de ton MLD a ta requete est plus "concevable" avec JOIN qu'en reléguant toutes les jointures dans le même sac, au beau mileu des clauses de filtrage a la fin de ta requete.

Je trouve que la technique clause where creuse le fossé entre le MLD et la requete.