Beginnen wir damit, dass ich niemals und ich meine niemals eine gespeicherte Prozedur in einem Trigger aufrufen würde. Um eine mehrzeilige Einfügung zu berücksichtigen, müssten Sie mit dem Cursor durch die Prozedur gehen. Das bedeutet, dass die 200.000 Zeilen, die Sie gerade durch eine mengenbasierte Abfrage geladen haben (z. B. alle Preise um 10 % aktualisieren), die Tabelle möglicherweise stundenlang sperren, während der Trigger tapfer versucht, die Last zu bewältigen. Außerdem könnten Sie, wenn sich etwas im Prozess ändert, alle Einfügungen in den Tisch beschädigen oder den Tisch sogar vollständig aufhängen. Ich bin fest davon überzeugt, dass der Triggercode nichts anderes außerhalb des Triggers aufrufen sollte.
Ich persönlich ziehe es vor, einfach meine Aufgabe zu erledigen. Wenn ich die Aktionen, die ich ausführen möchte, richtig in den Trigger geschrieben habe, wird er nur aktualisieren, löschen oder einfügen, wo sich Spalten geändert haben.
Beispiel:Angenommen, Sie möchten das Feld last_name aktualisieren, das Sie aufgrund einer dort aus Leistungsgründen platzierten Denormalisierung an zwei Stellen speichern.
update t
set lname = i.lname
from table2 t
join inserted i on t.fkfield = i.pkfield
where t.lname <>i.lname
Wie Sie sehen können, werden nur die lnames aktualisiert, die sich von denen unterscheiden, die sich derzeit in der Tabelle befinden, die ich aktualisiere.
Wenn Sie eine Prüfung durchführen und nur die geänderten Zeilen aufzeichnen möchten, führen Sie den Vergleich mit allen Feldern durch, so etwas wie i.field1 <> d.field1 oder i.field2 <> d.field3 (usw. durch alle Felder)
