Discussion :

[Pol63]

bonjour

j'ai souvent des tables avec des colonnes dont la valeur dépend d'autre colonne de la meme ou d'autre tables
j'ai donc en général des triggers pour faire les mises à jour

j'ai voulu tenter les colonnes calculées, que j'ai envie de mettre avec persistance car nos tables étant appelées assez souvent par plusieurs clients, j'ai pas envie de perdre de performance
pour des colonnes dont la valeur dépend de colonnes de la meme table, ca marche bien
mais pour les autres, apparemment il faudrait utiliser des fonctions en passant en paramètre un identifiant pour aller rechercher des infos dans d'autres tables, or pour la persistance, il veut des choses déterministes ...

si vous avez une solution faire des colonnes calculées sans utiliser de trigger je suis preneur
(en fait j'ai plusieurs triggers par table, que je ne peux pas mixer et qui font qu'au final pour une mise à jour j'arrive à plus de 15 appels de triggers, dont plusieurs fois les même)

merci

[elsuket]

Bonjour,

En supposant que les fonctions soient déterministes, il resterait quand même un problème de performance, car l'utilisation de fonction provoque un comportement RBAR, et je ne suis pas certain que vous y gagneriez par rapport au trigger.
Si les tables de base sont faiblement mises à jour, il est envisageable de passer par des fonctions.

Pour passer outre les triggers et les fonctions, ne vous est-il pas possible d'utiliser une vue (indexée ?) ?

@++

[Pol63]

les tables sont beaucoup plus souvent lues que mises à jour, et en général une ligne à la fois, donc l'utilisation dans ce cas de fonctions ne serait pas trop pénalisant

une vue avec un ch1*ch2 / ch3 ca sera quand meme moins performant que de lire une valeur directement, je ne pense pas qu'en passant par une vue, les résultats soient mis en cache !

et les triggers after insert,update, ca m'en fait un peu trop à mon gout et ca nous plante certaines choses
(on a aussi des triggers de "trace" sur certaines tables dont celles qui posent soucis, en insère dans une table d'historique tout ce qui est fait, avec en plus l'iduser et la date, donc si ce trigger est appelé plusieurs fois ca rempli un peu trop pour rien (en plus pas dans le bon ordre), ce qui est le cas en ce moment avec nos multiples triggers)

[elsuket]

une vue avec un ch1*ch2 / ch3 ca sera quand meme moins performant que de lire une valeur directement

A voir dans le cas d'une vue indexée

je ne pense pas qu'en passant par une vue, les résultats soient mis en cache !

ça j'en mettrais pas ma main à couper

n a aussi des triggers de "trace" sur certaines tables dont celles qui posent soucis, en insère dans une table d'historique tout ce qui est fait

Si vous êtes sous SQL Server 2008, peut-être que les fonctionnalités Change DataTracking ou Change Data Capture peuvent convenir à votre problématique.
Ces deux fonctionnalités sont peu gourmandes en ressources.

@++

[Pol63]

sql server 2005, et pas toujours en version entreprise (donc pas de vues indexées)

[elsuket]

Exact.
En revanche je reste assez certain ce que vous obtiendriez des performances correctes en utilisant une vue (n'oubliez pas l'option WITH SCHEMABINDING)

@++