Discussion :

[maxtin]

Bonjour, je me poses certaines questions sur la capacite des triggers en SQL2005. Jai une appli qui peut envoyer jusqua 200 entrees a la fois dans une table (possedant un trigger). Je me demande si ca risque de planter (je ne sais pas si SQL Server cree une queue afin de traiter ces 200 executions en serie..ou peut-etre un autre mecanisme?). En passant, le code de mon trigger gere aussi les entrees dont le trigger ne se serait pas fait executer (ie. si un trigger ne sexecute pas lors dun insertion..le prochain trigger lancer devrait sen occuper). Ai-je raison de minquieter? je songe comme alternative d'executer un job a toutes les x seconde afin de traiter les nouvelles entrees.

Merci infiniment

[SQLpro]

Bonjour,

le but d'un déclencheur est de compléter le traitement de l'information dans le cadre de la modification des lignes généré par un ordre SQL de mise à jour.

Dans ce sens, le trigger possède plusieurs particularités :
1° il s'exécute au sein de la transaction qui est généré par l'ordre SQL de mise à jour
2° il permet de connaître les valeurs avant et après de la modification à l'aide de pseudo table (inserted : nouvelles valeurs, deleted : anciennes valeurs)
3° dans SQL Server, il est ensembliste, c'est à dire que si vous insérez, supprimez ou modifier 100 lignes d'un seul coup (par un seul ordre SQL) il n'y aura qu'un seul déclenchement de trigger.

Dans un SGBD relationnel, tous les traitements sont fait de manière ensembliste. Il n'y a donc pas de question à se poser sur la façon (genre "file d'attente") dont le traitement est effectué. Au mieux, tout est fait en parallèle afin d'optimiser au maximum le traitement, dans sa durée. Ainsi on peut considérer (vue de l'esprit) que s'il y a 200 lignes à modifier, alors 200 threads peuvent le faire en parallèle...

Tout traitement que vous ferez hors du trigger sera plus complexe, nettement plus couteux et susceptible de conduire à l'incohérence de votre base de données. En effet, sans l'aspect transactionnel, un partie de votre traitement peu s'exécuter, mais pas une autre, rendant la base incohérente.

Lisez les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L3
http://sqlpro.developpez.com/cours/s...ransactsql/#L5

A +

[maxtin]

Merci beaucoup SQLPro, et pour la doc,

Dans le cas ou mes 200 entrees ne sont pas d'un seul coup (ex: 200 ordres SQL differents dans une meme seconde), alors SQL Server generera 200 threads en parallele, si je te suis bien. C'est plus a ce niveau que je m'inquiete (combien faut-il de threads paralleles avant de s'inquieter d'un manque de ressources ou autres problemes potentiels...assumant un trigger de complexite moyenne?)

J'assume que, dans un tel cas, les appels de trigger subsequent seront ignores...ce qui ne devrait pas m'affecter (considerant la capacite de gerance de mon code mentionne dans mon premier post)...tant et aussi longtemps qu'ils redeviennent fonctionnels lors de la liberation des ressources (svp me corriger si je n'ai pas raison ).