[MySQL] Trigger mettant à jour une autre table

Trigger mettant à jour une autre table [MySQL] - SQL/NoSQL - Programmation

Marsh Posté le 18-11-2007 à 15:50:25    

Salut à tous!
Je me creuse la tête depuis un bout de temps.....sans succès!
 
J'ai (pour faire très simple) :
Immeuble(id_immeuble,nb_logements)
Logement(id_logement,id_immeuble)
 
Je souhaite faire un trigger qui lors d'une insertion dans Logement, va incrémenter nb_logements. Facile à dire...
 
Donc à chaque nouvelle insertion de logement, je voudrais récupérer l'id_immeuble correspondant, et faire un UPDATE sur cet immeuble seulement.
 
CREATE TRIGGER maj_nb_logements AFTER INSERT ON Logement
FOR EACH ROW
BEGIN
UPDATE Immeuble SET nb_logements = nb_logements + 1
WHERE ????
END;
 
J'ai essayé diverses choses avec des LAST_INSERT_ID(), des NEW/OLD (dont je n'ai sûrement pas compris le sens), etc...
 
Si quelqu'un pouvait me donner une piste :jap:

Reply

Marsh Posté le 18-11-2007 à 15:50:25   

Reply

Marsh Posté le 19-11-2007 à 15:29:05    

quel sgbd ?
 
habituellement, dans un trigger tu as deux tables virtuelles "new" et "old" qui représentent l'ancienne ligne et la nouvelle ligne.
 
donc en gros, dans ton where, tu fais :
 

Code :
  1. WHERE immeuble.id = new.immeuble_id


Message édité par MagicBuzz le 19-11-2007 à 15:29:22
Reply

Marsh Posté le 19-11-2007 à 17:06:53    

Bonjour,
 
personnelement je metterai pas le nombre de logement ds la table Immeubre. quand tu veux cette info, tu fait un SELECT COUNT() FROM Immeuble WHERE id_immeuble = 'num de l'immeuble'
 
ou sinon apres insertion d'un nouveau logement:
UPDATE Immeuble SET nb_logement = nb_logement + 1
 
peut etre que je me trompe mais laissons les experts nous donner leurs point de vu ;)

Reply

Marsh Posté le 19-11-2007 à 17:14:50    

normalement, effectivement, on ne stock pas ce genre d'informations.
 
et surtout, le trigger devrait plutôt faire un count() plutôt qu'une incrémentation, ceci afin de garantir que le champ est bien à jour avec la bonne valeur à la fin d'une mise à jour (parceque sinon, on peut modifier une valeur déjà faussée, et donc conserver des valeurs fausses).
 
en MySQL, je ne sais pas si ça existe, mais sous SQL Server par exemple, on peut stocker des champs "calculés".
 
Ceci permet de résoudre simplement ce genre de problèmes de dénormaliosation : la table stocke non pas la valeur, mais la formule qui permet de la retrouver. une valeur "cache" est alors conservée, ce qui permet de ne pas à avoir à réévaluer à chaque lecture.
 
http://forum.hardware.fr/hfr/Progr [...] m#t1447241

Reply

Marsh Posté le 20-11-2007 à 09:47:09    

salut,
merci pour vos réponses...effectivement, cette information devrait être calculée et non pas stockée, ca paraît plus logique.
Je vais tout de même me renseigner sur toutes les infos que vous m'avez donné.
Merci encore!

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed