Salutation, Récemment, j'ai commencé à travailler sur une application, où 8 modules différents utilisent la même table à un moment donné dans le flux de travail. Cette table a un trigger Instead-Of, qui fait 5000 lignes (où les 500 premières et 500 dernières lignes sont communes à tous les modules, et ensuite chaque module a ses propres 500 lignes de code). Comme le nombre de modules va augmenter et que je veux garder les choses aussi claires (et séparées) que possible, je me demandais s'il y avait une sorte de meilleure pratique pour diviser le déclencheur en procédures stockées, ou si je devais tout laisser en un seul endroit ? P.S. Y aura-t-il des pénalités de performance pour appeler des procédures à partir du déclencheur et leur passer plus de 15 paramètres ?
Réponses
Trop de publicités?
Gardant à l'esprit que le inserted y deleted les pseudo-tables ne sont accessibles qu'à l'intérieur du code déclencheur, et qu'elles peuvent contenir multiple les rangs, vous êtes face à deux choix :
-
Traiter les lignes dans
insertedydeleteddans un RBAR 1 de façon à pouvoir passer des paramètres scalaires aux procédures stockées, ou, -
Copiez toutes les données de
insertedydeleteddans des variables de table qui sont ensuite transmises aux procédures comme il convient.
Je m'attendrais à ce que l'une ou l'autre approche impose 2 une surcharge de performance, juste à cause de la copie
Cela dit, il semble que trop de choses se passent à l'intérieur des déclencheurs eux-mêmes - tout ce code doit-il faire partie de la même transaction qui a exécuté l'instruction DML ? Si ce n'est pas le cas, envisagez d'utiliser une forme de file d'attente (une table de requêtes ou Service Broker, par exemple) dans laquelle vous placerez les informations sur le travail à effectuer, puis traiterez les données ultérieurement. Si vous utilisez Service Broker, vous pourriez lui demander d'inspecter un message partagé puis d'envoyer les messages appropriés à des points de terminaison dédiés pour chacun de vos modules, le cas échéant.
1 Row By Agonizing Row - en utilisant soit un cursor de quelque chose d'autre pour simuler l'accès à chaque ligne tour à tour - ce qui est généralement mal vu dans un langage basé sur les ensembles comme SQL.
2 Il est impossible de savoir dans quelle mesure sans entrer dans les détails de votre code, sans essayer toutes les approches possibles et sans mesurer le résultat.
Je ne pense pas qu'il y ait une pénalité de performance significative dans ce cas.
De toute façon, c'est une mauvaise pratique de tout écrire dans le trigger (quand il fait 5000 lignes...). Je pense que la principale considération est la maintenabilité, qui sera bien meilleure si vous la divisez vers plusieurs SPs
