Antwort.

Gespeicherte Prozeduren (stored procedures) – programmierbare Blöcke, die explizit aufgerufen werden und Parameter annehmen können, komplexe Geschäftslogik ausführen, mit Transaktionen arbeiten sowie Datensätze oder Ausgangsparameter zurückgeben.

Trigger (triggers) – spezielle Objekte, die "automatisch" auf Ereignisse der Datenänderung (INSERT, UPDATE, DELETE) reagiert werden und die transparente Ausführung der festgelegten Logik bei bestimmten Aktionen auf der Tabelle gewährleisten.

Wann Prozeduren verwenden

• Notwendigkeit zur Verarbeitung großer Datenmengen.
• Erforderliche explizite Transaktionskontrolle.
• Ergebnis oder mehrere Datensätze zurückgeben müssen.

Wann Trigger verwenden

• Gewährleistung von impliziten Prüfungen oder Aktualisierungen bei jeder Datenänderung (z.B. Auditing).
• Notwendigkeit zur Implementierung durchgängiger Integritätsprüfungen.

Beispielcode

Gespeicherte Prozedur:

CREATE PROCEDURE UpdateProductPrice
  @ProductID int, @NewPrice money
AS
BEGIN
  UPDATE Products SET Price = @NewPrice WHERE ProductID = @ProductID;
END

Trigger:

CREATE TRIGGER trg_ProductsPriceChange
ON Products
AFTER UPDATE
AS
BEGIN
  INSERT INTO PriceAuditLog(ProductID, OldPrice, NewPrice, ChangeDate)
  SELECT i.ProductID, d.Price, i.Price, GETDATE()
  FROM inserted i JOIN deleted d ON i.ProductID = d.ProductID
  WHERE i.Price <> d.Price
END

Fangfrage.

Q: Kann man die Reihenfolge der Ausführung mehrerer AFTER-Trigger auf einer Tabelle in SQL Server mit Standardmitteln bestimmen?

A: Nein, der SQL-Standard garantiert nicht die Reihenfolge der Ausführung von AFTER-Triggern gleicher Richtung auf einer Tabelle. Wenn die Reihenfolge wichtig ist, sollten diese in einem zusammengefasst werden.

Beispiele für reale Fehler aufgrund fehlenden Wissens über die Feinheiten des Themas.

---

Geschichte

In einer CRM-Lösung zur Unterstützung der Funktionalität zur Historie von Änderungen wurden Trigger verwendet. Aufgrund der hohen Last von Massenaktualisierungen gelangten logische Einträge mit Verzögerung in das Protokoll und blockierten "operative" Vorgänge, was zur vorübergehenden Nichtverfügbarkeit des Dienstes führte.

---

Geschichte

Ein Entwickler erstellte die Logik zur Datenprüfung nicht in einer Prozedur, sondern in einem Trigger, in der Erwartung, dass die Änderungen für den Benutzer sofort sichtbar sein würden. Vergessend, dass der Trigger "transparent" ist, stellte er fest, dass die Geschäftslogik nicht offensichtlich ("magisch") wurde und schwer zu debuggen war.

---

Geschichte

Wichtig: Oft wird eine Prozedur innerhalb eines Triggers aufgerufen oder ein Trigger aus einer Prozedur, was zu Rekursion und Überschreitung der Verschachtelungstiefe führt – zum Beispiel führt eine automatische Einfügung zur erneuten Auslösung des Triggers über die verbundene Prozedur.