Je ne pense pas que vous pouvez les combiner simplement parce que FOR UPDATE fonctionne avant que le TSQL ne soit exécuté alors que AFTER UPDATE est fait après que l'exécution soit terminée.
La performance dépend entièrement de la qualité de votre code.
Il n'y a pas de différence de performance si le même code est dans un déclencheur ou deux déclencheurs.
Au cours des trois dernières années, je n'ai pas encore rencontré une seule chose que je ne pouvais pas faire sans déclencheurs. Je reste personnellement loin des déclencheurs autant que possible. Ils sont aussi faciles à modifier que n'importe quelle autre instruction SQL, mais ils sont les facteurs cachés derrière toute opération d'édition sur les données, et à ce titre, je m'en méfie.
Si vous souhaitez que votre déclencheur soit exécuté pour une mise à jour en masse, vous devez le coder de cette façon, sinon vous l'exécuterez pour la dernière ligne. Par exemple, disons qu'un déclencheur prend 1 seconde pour s'exécuter. Si vous faites un RBAR et exécutez une mise à jour valant 100 lignes, votre requête SQL ne retournera pas avant 1 minute 40 secondes.
Assez curieusement, la plupart des développeurs que j'ai trouvé qui utilisent des déclencheurs (sauf INSTEAD-OF) sont également friands de curseurs.
Dans l'ensemble, mon 2-pence est de rester loin d'eux autant que possible.
Cette dernière instruction n'est pas vraie. Un déclencheur dans SQL Server s'exécute une fois pour l'ensemble des données en cours de mise à jour. Il ne fonctionne pas une fois pour chaque ligne. En supposant que vous l'avez codé correctement et de manière fixe, vous ne devriez voir nulle part une croissance linéaire. Je suis d'accord avec vos autres raisons de se méfier des déclencheurs cependant. –
@Tom H réponse aux commentaires –