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.

[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

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

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

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

[Feeder_Fan]

Lorsque tu dis

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

je ne peux qu'�tre d'accord avec toi.

Cependant dans le cas pr�sent, il n'y a pas d'op�rations de filtrage supl�mentaire autre que ma jointure donc il ne peut y avoir d'embiguit�.
J'y suis certes all� un peut fort sur le coups du acad�mique, mais ce que je veux dire, c'est qu'il n'y a jamais une seule facon d'arriver � ses fins et dans le cas pr�sent (car c'est ce qui nous int�resse ici) si mealtone n'est pas � l'aise avec une m�thode je lui en fournis une autre.

D'ailleurs � propos du d�bat sur la m�thode de former ses jointures, je constate que 22 % cons�rvent leurs jointures dans le WHERE. C'est bien pour une raison qui n'est peut �tre pas le refus du progr�s mais qui est tout simplement d'ordre pratique.

Sur ce je n'ai rien � ajouter si ce n'est que j'utilise les deux m�thodes selon certaines configurations.

[gisele]

Salut Luc,

qu� troll? je trouve sain de dicuter sur ce sujet.

Je pose un probl�me concret qui pourrait paraitre farfelu mais c'est pour poser un pr�texte � l'utilisation d'un UPDATE multi-tables.

Admettons que je veuille augmenter de 10 le prix de toutes les prestations d�pendant de la ville de mufflins :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
UPDATE prestation JOIN ville USING(IDVILLE)
SET prix = (prix + 10)
WHERE NOMVILLE LIKE 'mufflins'

Bien sur on peut techniquement UPDATER en une requete des champs de tables diff�rentes, c'est souvent le cas pour des besoins de maintenances :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
UPDATE prestation p JOIN ville v USING(IDVILLE)
SET p.IDVILLE =10,v.IDVILLE=10
WHERE NOMVILLE LIKE 'mufflins'

[Luc Orient]

...

Je pose un probl�me concret qui pourrait paraitre farfelu mais c'est pour poser un pr�texte � l'utilisation d'un UPDATE multi-tables.

Admettons que je veuille augmenter de 10 le prix de toutes les prestations d�pendant de la ville de mufflins :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
UPDATE prestation JOIN ville USING(IDVILLE)
SET prix = (prix + 10)
WHERE NOMVILLE LIKE 'mufflins'

Bien sur on peut techniquement UPDATER en une requete des champs de tables diff�rentes, c'est souvent le cas pour des besoins de maintenances :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
UPDATE prestation p JOIN ville v USING(IDVILLE)
SET p.IDVILLE =10,v.IDVILLE=10
WHERE NOMVILLE LIKE 'mufflins'

�a m'�tonnerait fort que �a marche cette syntaxe ....
Sur quel SGBD SVP ?

[gisele]

Salut tous,

je suis parfois emmen� � faire des requetes UPDATE multi-tables au taf, je sais assur�ment que �� marche sur Mysql >= 4.1.
Ces syntaxes sont souvent pratiques sur des mod�les de donn�es imparfaits , genre mal normalis�s (et dont il a fallu s'accomoder) , ou pour les stats de prod�.

Mais tu peux verifier par toi m�me, je vais m�me te faciliter la chose :

Si tu as un mysql sous la main cr�e ces 2 tables tests pr�remplies :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
 
CREATE TABLE `marque` (
  `id_marque` int(11) NOT NULL auto_increment,
  `nom_marque` varchar(50) NOT NULL,
  PRIMARY KEY  (`id_marque`)
) ENGINE=MyISAM;
 
 
INSERT INTO `marque` (`id_marque`, `nom_marque`) VALUES 
(1, 'RENAULT'),
(2, 'PEUGEOT'),
(3, 'TOTO');

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
CREATE TABLE `modele` (
  `id_modele` int(11) NOT NULL auto_increment,
  `type` varchar(50) NOT NULL,
  `id_marque` int(11) NOT NULL,
  PRIMARY KEY  (`id_modele`)
) ENGINE=MyISAM DEFAULT ;
 
INSERT INTO `modele` (`id_modele`, `type`, `id_marque`) VALUES 
(10, '1.2L', 3),
(1, '1.5 L', 2),
(2, '1.9 D', 1),
(3, 'TITI', 0),
(4, '2.5M', 2),
(5, '3.2H', 2),
(6, '1.3', 2),
(7, '2.5 k', 3),
(8, '1.0M', 3),
(9, '3.2M', 1);

puis essaie �� et regarde ce que �� donne :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
UPDATE modele JOIN marque USING(id_marque)
SET type = concat(type, ' de chez Peugeot')
WHERE nom_marque LIKE 'PEUGEOT'

puis essais �� et regarde ce que �� donne :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
UPDATE modele mo JOIN marque ma USING(id_marque)
SET mo.id_marque = 10,ma.id_marque = 10
WHERE nom_marque LIKE 'PEUGEOT'

[Luc Orient]

Salut tous,

je suis parfois emmen� � faire des requetes UPDATE multi-tables au taf, je sais assur�ment que �� marche sur Mysql >= 4.1.
Ces syntaxes sont souvent pratiques sur des mod�les de donn�es imparfaits , genre mal normalis�s (et dont il a fallu s'accomoder) , ou pour les stats de prod�.

Mais tu peux verifier par toi m�me, je vais m�me te faciliter la chose :

Si tu as un mysql sous la main cr�e ces 2 tables tests pr�remplies :
...

D�sol�, mais je n'ai pas un mysql sous la main ...

Moi j'utilise DB2 for z/OS V7 au travail (je n'ai pas de Mainframe chez moi ... ) et je sais qu'il n'est pas possible de coder un UPDATE sur plusieurs tables avec ce SGBD.

En tout cas cela confirme l'opinion que j'avais sur mysql, � savoir un SGBD, disons ... un tantinet "baroque"

De plus il faudra actualiser le cours SQL sur DVP car on peut y lire :

.. les mises � jour en SQL ...
Pr�ambule :
Il existe une diff�rence fondamentale entre l'ordre de manipulation des donn�es qu'est le SELECT et les diff�rents ordres de mise � jour de donn�es :

/ ... plusieurs diff�rences sont cit�es dont : /

• parce qu'autant il est possible d'effectuer des extractions de donn�es via un ordre SELECT sur plusieurs tables, autant il est impossible d'ins�rer, de modifier ou de supprimer dans plusieurs tables simultan�ment

Source :
http://sql.developpez.com/sqlaz/dml/#L0

[gisele]

Qu'est ce que tu as contre le baroque?
pour moi Bach est le plus grand de tout le temps, tous art confondu.
et je te dis �� le plus subjectivement du monde

Sinon, je ne vais pas me plaindre du fait que mysql permette l'�criture sur plusieurs tables en simultann� (seulement pour les UPDATE je pr�cise), a fortiori si cela est au service de l'int�grit� des donn�es.

Certes ca n'est qu'une solution de plus parmi d'autres pour les rapport (PK FK) o� les triggers peuvent tenir leur r�le, mais pas seulement.
J'ai rencontr� des cas de redondance de champs sur 2 tables o� j'�tais bien content de pouvoir faire d'une pierre 2 coups.
Comme je l'ai dit on est parfois oblig� de faire avec des mod�les plus ou moins normalis�s

Parcontre il me semble bien que l'update d'une table en fonction d'une autre est couramment permis chez les SGBD ne serait ce que gr�ce aux sous-requetes :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
 
UPDATE table1
SET champ1='valeur1'
WHERE id=(
SELECT id FROM table2
WHERE champ='valeur'
)

Ce qui mettra peut �tre un petit b�mol classique � Mysql c'est comme tous les SGBD,il interdira l'update et la lecture simultan� d'une table.
Je pense que :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
 
UPDATE table1
SET champ1='valeur1'
WHERE id=(
SELECT max(id) FROM table1
)

renverra une erreur du genre "can't Update table1 .."

Baroque mais pas d�raisonnable

[mealtone]

Ouf j'ai jamais eu autant de r�ponses � mes questions
merci � vous j'ai de quoi lire la

[mealtone]

ba didon, apr�s lecture, �a fait peur de savoir qu'il y a encore autant de choses a connaitre, je vais y passer mes dix prochaines ann�es , tout en sachant que dans dix ans, ce sera une toute autre histoire, alala le progr�s...
Si vous avez de bons livres � me conseiller, ce serai le bienvenu
Dans tous les cas, elle marche � merveille ta requ�te gis�le merci