Dans ma philosophie de l’épure j’ai toujours un frisson quand je découvre ce genre de code … Déjà que je ne suis pas fan des triggers… mais si en plussse je trouve des beautés pareilles…je ne résiste pas à les partager
Pourquoi diable faire simple ? Mais ne diabolisons pas… il y a encore de la place pour la formation après tout! J’aimerais quand même savoir si apprendre aux jeunes Padawans développeurs à faire en premier des boucles à tout crin ne les pervertit pas à jamais*… C’est si gai ces petits moulins à vents…Et les voilà condamnés au traitement goutte à goutte au lieu d’ouvrir grand les vannes comme il se doit pour que la donnée passe et coule…de source…
Après exégèse l’usage de ce trigger consiste à remplir une table de log via une procédure .
On aurait pu donc tout aussi bien insérer directement cette table depuis le trigger en utilisant les tables inserted ou deleted sans plus de fioriture: nul besoin de variables, ni de curseur, ni de procédure.
N’oublions pas que toute instruction contenue dans un trigger fait partie de la transaction elle même: c’est le carnage pour la contention. En plus notre curseur ici va appeler la procédure a chaque itération…
Et puis bah il y a des trucs plus moderne genre le Change Tracking…pour n’en citer qu’un…
Bref, après on peut imaginer que ce trigger est reproduit sur toutes les tables chaudes comme disent nos copains anglos-saxon… Et on vient encore pleurer que l’IO s’envole…ou que ca verrouille trop —viite un No Lock…
* Il faudrait commencer par leur faire faire des requêtes dans tous les sens…. et ne toucher à d’autres langage de programmation qu’après avoir souffert IO par IO na!
DatAtypical 