Update d'une table destination à partir d'une table source

Bonjour mon problème est un peu long à expliquer pour le profane que je suis...Je vais donc essayer de me lancer :
J'ai une table source (databrute) qui contient des données (id,annee,mois,jour,heure,montant,dateKey,operation) et une autre table destination (finalData) avec la même structure.
Ce que je voudrais faire, c'est la somme (montant) de source pour une heure donnée et stocker cette somme dans la colonne montant de la table destination... Je vous donne un exemple

TABLE SOURCE:
id;annee;mois;jour;heure;montant;dateKey;operation
1; 2010; 2; 23; 2; 1000; 2010022302; X
1; 2010; 2; 23; 2; 3000; 2010022302; X
1; 2010; 2; 23; 2; 7000; 2010022302; Y
1; 2010; 2; 23; 2; 3500; 2010022302; Y

TABLE DESTINATION (resultat attendu) :
id;annee;mois;jour;heure;montant;dateKey;operation
1; 2010; 2; 23; 2; 4000; 2010022302; X
1; 2010; 2; 23; 2; 10500; 2010022302; Y

cela me permettra de réduire considérablement le nombre de lignes quand on sait que par heure je peux avoir 3000 lignes pour une opération donnée!

j'ai moi même créé et rempli le champ datakey pour créer une clé unique me permettant de faire la jointure entre les deux tables pour la mise à jour.

je précise que la table destination est déjà pré-remplie avec toutes les dates et heures possibles de l'année, le champ montant à 0 par défaut et qu'il faut le mettre à jour avec la somme des montants des heures de source pour la même heure...

Quelqu'un peut-il m'aider pour la requête à effectuer ? Désolé de vous donner des minutes de lecture aussi longues....

voici ma requête qui ne marche pas:

Code:

---

1 2 3 4 5 6 7

update finalData f, databrute d set montant = (select sum(montant) from databrute where d.annee=f.annee and d.mois=f.mois and d.jour=f.jour and d.heure=f.heure and f.operation=d.operation) where d.datekey=f.datekey

---

Saluton,
Moi j'essayerais comme ça

Code:

---

1 2 3 4 5 6 7 8 9 10 11

UPDATE finalData f SET montant = s.somme INNER JOIN (SELECT sum(d.montant) AS somme, d.datekey FROM databrute d WHERE d.annee=f.annee AND d.mois=f.mois AND d.jour=f.jour AND d.heure=f.heure AND f.operation=d.operation GROUP BY d.datekey) s ON f.datekey=s.datekey

---

Bonjour Kris,
je te remercie pour ta reponse rapide.
J'ai essayé ta requête et j'ai toujours un problème.
Le fait de faire UPDATE finalData f d ne pose t-il pas de problème niveau syntaxe?
De plus peux tu m'expliquer ce que represente ta variable s, car il me semble que le resultat de la requete est déja stocké dans la variable 'somme'
Merci d'avance :oops:

Désolé, j'ai modifié ma proposition de requête.
En fait, je surnomme chaque table de son initiale et je donne aussi un surnom, s, à la sous-requête.
C'est pourquoi je préfixe les noms de colonnes du surnom des tables.

Bonjour finalement j'ai résolu mon problème après être passé ici...
Au lieu d'avoir dans la table finalData la colonne "operation" qui contient 5 valeurs possibles, j'ai crée cinq variables dans cette table et chaque variable correspond à une opération, puis je fais une seule requête qui met à jour les 5 colonnes simultanément comme suit:

UPDATE finalData set
var_op1=SELECT SUM(montant)
FROM databrute where operation="op1" and jour=j and mois=m and annee=a,
var_op2=SELECT SUM(montant)
FROM databrute where operation="op2" and jour=j and mois=m and annee=a,
var_op3=SELECT SUM(montant)
FROM databrute where operation="op3" and jour=j and mois=m and annee=a,
var_op4=SELECT SUM(montant)
FROM databrute where operation="op3" and jour=j and mois=m and annee=a,
var_op5=SELECT SUM(montant)
FROM databrute where operation="op4" and jour=j and mois=m and annee=a
WHERE datekey="datekey"


Je précise que dans mon cas je devais faire un CRON pour automatiser tout le process, et donc dans le script qui est appelé par le CRON, on a pu récupérer les paramètres j,m,a dans la date courante du système...(merci à notre ingénieur système :ccool: )
De la même façon datekey est "fabriqué" avec les paramètres de la date du jour, donc à la fin on obtient une requête dynamique qui s'exécute chaque jour.

Cela nous prend 25 secondes pour traiter 150.000 lignes, comme notre CRON est lancé chaque jour à 2h du matin, on s'en fout que ça soit pas optimal car on a besoin des résultats que vers 8h du matin!
-----------------------------------------------------------------------
La conclusion de tout ceci est qu'il fallait résoudre le problème à la base c'est à dire au niveau de la conception de la table destination.

En tout cas merci d'avoir crée cet espace et j'espère aller dans les forums en rapport avec mon activité pour apporter mon aide si je peux....:oops: