Discussion :

[speedev]

Bonjour,

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

Exemple :

Code :

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

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.

[Antoun]

Normalement, on ferait plutôt ça :

Code :

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

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

[speedev]

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

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

Code :

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

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) ;

[Antoun]

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

[speedev]

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" ?

[Antoun]

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

[speedev]

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.

[Antoun]

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

Fais un voeu

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

[speedev]

Fais un voeu

Je fais le vœu que ça marche

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

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

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 +

[speedev]

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

[Antoun]

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.