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.