Discussion :

[Gérard69]

Bonjour à tous,

Je n'ai pas vraiment trouvé dans le forum la réponse à cette question simple :

Comment écrire en MySQL,
la requête suivante écrite en Oracle_SQL, qui met à jour la table "Services" à partir de calculs sur la table "Employés" :

Update Services S
set (Nb_Emp, Mt_Salaires) = (
select count(*), sum(Salaire)
from Employés E
where E.id_service = S.id_service)

Merci d'avance pour vos réponses

Bien cordialement

PS : J'ai simplifié au maximum évidemment, mais dans la pratique, les requêtes de ce genre contiennent de nombreux calculs, des "décode" (Oracle) ou "if" ou "case" et autres formules mathématiques, et tout cela évite le recours à des L3G et autres curseurs, avec parcours de table ligne par ligne.

[SQLpro]

MySQL a un niveau de SQL qui à plus de 20 ans de retard. Il en est resté à avant la norme SQL 2 de 1992. EN particulier il ne sait pas gérer le ROW VALUE CONSTRUCTOR.
A lire : http://sqlpro.developpez.com/cours/sqlaz/select/#L8
Il faut donc récrire entièrement cette requête en tenant compte des limites de MySQL.

Bon courage

A lire en complément : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

[Gérard69]

Un problème aussi simple ne devrait pas nécessiter le recours à des fonctionnalités "pointues" implémentées par seulement quelques SGBD.

Comme je l'ai dit, lorsque l'on développe des applications complexes, sans L3G, donc avec toutes sortes d'algorithmes, ce genre de calcul est fréquent.
Par exemple :
* mise à jour des capacités des machines d'un atelier ce jour, en fonction des arrêts programmés ce jour.
* calcul des besoins en matières premières pour toutes les commandes prévues avec des contraintes de délais de livraison, .....
Et bien plus compliqué que cela encore.

J'ai développé (il y a longtemps en Oracle 7) tout un ERP sans utiliser un seul parcours ligne par ligne (avec curseur ou L3G ni PL-SQL), que de l'algèbre relationnelle, du SQL-Forms avec triggers en SQL.
Pour cela, j'ai énormément utilisé des Update multi-colonnes alimentés par des sous-requêtes avec des claculs (sommes, formules, puissance) et surtout des fonctions "decode" imbriquées qui permettent de faire de l'algorithmie.
Le "decode" d'Oracle semble pouvoir être remplacé par le "IF()" et/ou le "case" dans MySQL.

Mais franchement, si en 2014, on ne peut pas faire simplement dans MySQL la requête suivante écrite en Oracle (5, 6 ou 7) en 1990 .... alors là ... le monde va à reculons :

Update Services S
....set (Nb_Emp, Mt_Salaires) = (
........select count(*), sum(Salaire)
........from Employés E
........where E.id_service = S.id_service)

Nul doute que sur ce forum quelqu'un a déjà dû faire un update d'au moins 2 attributs qui dépendent d'une seule requête !!!!
Même sans calcul, comme cet exemple idiot mettant à jour une table à une seule ligne :

Update Gagnant_du_mois G
Set (Nom, Prénom) = (
....select Nom, Prénom
....from Individus I
....Where I.id_individu = <un_nombre_aléatoire>)
Where
....G.id_individu = 1

Merci d'avance de vos réponses

[SQLpro]

N'oubliez pas que MySQL n'est même pas encore conforme à la norme SQL de 1992 !

A +

[Gérard69]

Bonjour SQLpro,

J'ai bien compris, et ne cherche pas à "faire de la même façon".

Mais mes questions simplifiées sont tellement basiques, qu'elles ont dû se poser des milliers de fois et je ne peux envisager une seconde qu'il n'existe pas une solution simple et élégante de faire cela dans MySQL, tout en "retard" qu'il soit.

Je m'attendais par exemple à avoir une réponse sur le principe de l'Update multitable avec jointure de MySQL,
tout au moins pour mon dernier exemple sans fonction de groupe.

Je garde espoir, et reste en attente des réponses des participants.

Bonne journée

[aieeeuuuuu]

Bonjour,

Vous pouvez faire comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
UPDATE Service S
INNER JOIN (
		SELECT
			id_service, 
			count(*) as cnt, 
			SUM(salaire) as tot
		FROM Employe 
		GROUP BY id_service 
	) E
	ON E.id_service = S.id_service
SET 
	nb_emp = cnt, 
	mt_salaire = tot;