Commençons par je ne ferais jamais et je veux dire jamais invoquer un proc stocké dans un déclencheur. Pour tenir compte d'une insertion multi-lignes, vous devez faire défiler le proc. Cela signifie que les 200 000 lignes que vous venez de charger via une requête basée sur un ensemble (par exemple, mettre à jour tous les prix de 10 %) pourraient bien verrouiller la table pendant des heures alors que le déclencheur tente vaillamment de gérer la charge. De plus, si quelque chose change dans le processus, vous pouvez casser tous les inserts de la table ou même raccrocher complètement la table. Je suis convaincu que le code du déclencheur ne devrait rien appeler d'autre en dehors du déclencheur.
Personnellement, je préfère simplement faire ma tâche. Si j'ai écrit les actions que je veux faire correctement dans le déclencheur, il ne fera que mettre à jour, supprimer ou insérer là où les colonnes ont changé.
Exemple :supposons que vous souhaitiez mettre à jour le champ last_name que vous stockez à deux endroits en raison d'une dénormalisation placée à cet endroit pour des raisons de performances.
update t
set lname = i.lname
from table2 t
join inserted i on t.fkfield = i.pkfield
where t.lname <>i.lname
Comme vous pouvez le voir, cela ne mettrait à jour que les noms de domaine qui sont différents de ce qui se trouve actuellement dans le tableau que je mets à jour.
Si vous souhaitez effectuer un audit et enregistrer uniquement les lignes qui ont changé, effectuez la comparaison en utilisant tous les champs quelque chose comme où i.field1 <> d.field1 ou i.field2 <> d.field3 (etc à travers tous les champs)
