Cominciamo con che non invocherei mai e intendo mai invocare un processo memorizzato in un trigger. Per tenere conto di un inserimento su più righe è necessario scorrere il proc. Ciò significa che le 200.000 righe che hai appena caricato tramite una query basata su set (ad esempio l'aggiornamento di tutti i prezzi del 10%) potrebbero bloccare la tabella per ore mentre il trigger cerca valorosamente di gestire il carico. Inoltre, se qualcosa cambia nel processo, potresti rompere qualsiasi inserto sul tavolo o addirittura riattaccare completamente il tavolo. Sono fermamente convinto che il codice trigger non dovrebbe chiamare nient'altro al di fuori del trigger.
Personalmente preferisco fare semplicemente il mio compito. Se ho scritto le azioni che voglio eseguire correttamente nel trigger, si aggiornerà, cancellerà o inserirà solo le colonne dove sono state modificate.
Esempio:supponiamo di voler aggiornare il campo cognome che stai archiviando in due posizioni a causa di una denormalizzazione posizionata lì per motivi di prestazioni.
update t
set lname = i.lname
from table2 t
join inserted i on t.fkfield = i.pkfield
where t.lname <>i.lname
Come puoi vedere, aggiornerebbe solo i nomi che sono diversi da quelli attualmente nella tabella che sto aggiornando.
Se vuoi fare il controllo e registrare solo quelle righe che sono cambiate, fai il confronto usando tutti i campi qualcosa come dove i.field1 <> d.field1 o i.field2 <> d.field3 (ecc attraverso tutti i campi)
