problème Trigger sur table unique

Bonjour,

Est-il possible de faire ceci ?
Seule matable est concernée par les opérations.

Exemple :

Code:

---

1 2 3 4 5 6

CREATE TRIGGER montrigger AFTER INSERT ON matable FOR EACH ROW BEGIN UPDATE matable SET NEW.monchamp=NEW.autrechamp-4; END;

---

"NEW.monchamp" est un champ "vide" à l'insertion mais après l'insertion je souhaite qu'il prenne directement la valeur modifée d'un "autrechamp".


Merci.

Normalement, on ferait plutôt ça :

Code:

---

1 2 3

CREATE TRIGGER montrigger BEFORE INSERT ON matable FOR EACH ROW SET NEW.monchamp = NEW.autrechamp - 4 ;

---

Ok j'ignorais cette possibilité, je vais essayer merci !

Tant qu'on y est, ceci reste jouable avec ta syntaxe ?

Code:

---

1 2 3 4

CREATE TRIGGER montrigger BEFORE INSERT ON matable FOR EACH ROW SET NEW.monchamp = NEW.autrechamp - (SELECT coalesce(sum(other),0) FROM autretable WHERE bidule=autre) ;

---

Tant que ta sous-requête ne renvoie qu'une seule ligne, ça doit le faire.

Au passage, tout ça est une scandaleuse dénormalisation :aie:

Citation:

---

Au passage, tout ça est une scandaleuse dénormalisation

---

Au passage tu peux m'expliquer ce que tu veux dire ?
Je n'ai pas compris ce qui était une "scandaleuse dénormalisation" ? :aie:

La normalisation exige (entre autres) qu'on ne stocke dans la base que des données élémentaires et non des données calculées. Par exemple, ta colonne qui est toujours égale à une autre colonne moins 4 ne devrait pas exister (en termes de normalisation - tu peux avoir de bonnes raisons de le faire quand même, notamment pour des questions de perf).

Ok.
Actuellement c'est pour des raisons de perf effectivement, il s'agit de mettre à jour des stocks automatiquement.
Des Vues SQL étaient trop lourdes à manipuler.
Des traitements PHP auraient été trop imposants et difficile à maintenir.

J'ai choisi les triggers...mais c'est la première fois que j'en manipule.

Citation:

---

Envoyé par speedev

J'ai choisi les triggers...mais c'est la première fois que j'en manipule.

---

Fais un voeu :D

Il ne faudrait pas créer les mêmes triggers sur le BEFORE UPDATE ?

Citation:

---

Fais un voeu :D

---

Je fais le vœu que ça marche :D

Citation:

---

Il ne faudrait pas créer les mêmes triggers sur le BEFORE UPDATE ?

---

Non (mais pour répondre implicitement à ta remarque oui j'ai déjà remarqué les subtilités des triggers qui demandent à penser plus d'une fois à leur utilisation :) ).

Merci

Le problème c'est qu'un trigger est BEAUCOUP plus couteux en général qu'un simple SELECT même avec des calculs. C'est pourquoi cette soit-disante dénormalisation dont le but est un gain de performances risque fort d'être une perte de performances. En effet toute mise à jour est transactionnée (donc écrite dans le JT) alors qu'un SELECT ne l'est pas !

En tout état de cause, avant de dénormaliser on commence par normaliser, puis on met le modèle à l'épreuve de la monté en charge (par exemple en populant les tables avec quelques centaines de milliers de lignes et en lançant plusieurs dizaines d'utilisateur simultanés). La on compare et si un gain réel, mesurable et significatif est obtenu alors on peut considérer comme bénéfique la dénormalistion.

Discussion récurrente que nous avons depuis des années ici même :
http://www.developpez.net/forums/d62...isation-table/

A +

J'ai fais des montées en charge avec Jmeter (apache) et c'est pourquoi je suis passé sur des triggers. Le soucis était lié à une vues SQL tenant à jour les stocks de produits en vente sur le site. Cette vue était excessivement gourmande pour le serveur SQL et de façon exponentielle en fonction de la quantité d'utilisateurs connectés (logique).
Les triggers ont immédiatement résolus le problème.

Mon soucis se pose plus sur la stabilité des triggers et à la maintenance de l'appli lorsque ces derniers déconnent (je n'ai pas trouvé encore de solution pratique pour contrôler les triggers).

Citation:

---

Envoyé par SQLpro

Le problème c'est qu'un trigger est BEAUCOUP plus couteux en général qu'un simple SELECT même avec des calculs. C'est pourquoi cette soit-disante dénormalisation dont le but est un gain de performances risque fort d'être une perte de performances. En effet toute mise à jour est transactionnée (donc écrite dans le JT) alors qu'un SELECT ne l'est pas !

---

Parler de performance en général ne veut rien dire. Une dénormalisation comme celle-ci améliore les performance du SELECT au détriment de celles de l'INSERT. Ça peut donc être pertinent ou non selon le profil d'utilisation.