Vor- und Nachteile von Trigger vs. Stored Procedures für Denormalisierung

Question

Wenn es darum geht, für die Performance-Daten in einer transaktionalen Datenbank Denormalisierung gibt es (mindestens) drei verschiedene Ansätze:

1. Push-Updates über gespeicherte Prozeduren des Aktualisierung sowohl der normalisierten Transaktionsdaten als auch der denormalisierten Berichts-/Analysedaten;

2. Implementieren Sie Trigger für die Transaktionstabellen, die die sekundären Tabellen aktualisieren. Dies ist fast immer der Weg, der bei der Pflege von Geschichten genommen wird;

3. Die Verarbeitung auf einen nächtlichen Batch-Prozess verzögern, möglicherweise ETL in ein Data Mart/Warehouse.

die für die Zwecke dieser Frage 3 die Option annehmen Lassen # nicht lebensfähig ist, da die Domäne der normalisierte Daten erfordert jederzeit mit den normalisierten Daten konsistent sein. Hierarchische Aggregate, mit denen ich mich ziemlich oft beschäftige, sind ein Beispiel dafür.

Ich habe beide der ersten beiden Ansätze ein gutes Stück verwendet und in letzter Zeit habe ich mich auf den Trigger-basierten Ansatz gelehnt, aber ich frage mich, ob es irgendwelche "gotchas" gibt, die ich noch nicht entdeckt habe und dachte, dass es sich lohnen würde, diese Frage zu stellen, damit ich einige Ideen im Hinterkopf behalten kann, wenn ich langfristige Entscheidungen in der Zukunft treffe.

Was sind Ihrer Meinung nach die Vor- und Nachteile beider Tools für den speziellen Zweck der Echtzeitspeicherung derormalisierter Daten? In welchen Situationen würdest du eins wählen und warum?

(PS Bitte keine Antworten wie „Trigger zu kompliziert ist“ oder „alle Updates sollte immer eine gespeicherte Prozedur durchmachen“ - es auf den Kontext der Frage angemessen machen.)

Answer 1

Trigger sind nützlich, wenn Sie mehr Aktualisiere Pfade auf einer Tabelle.

Wir verwenden gespeicherte Procs und haben etwa 4 Pfade mindestens (Hinzufügen, Aktualisieren, Deaktivieren Copy)

Es ist einfacher, mit den Daten zu arbeiten, haben wir gerade eingefügt/in einem Trigger aktualisiert, egal welche Maßnahmen wir oder wie viele Zeilen wir beeinflussen.

Eine gespeicherte Prozedur für einen einzelnen Update-Pfad funktioniert nur, ich fühle mich: es sei denn, Sie Code wiederholen mögen ...

Nun TRY/CATCH in Triggern bedeutet richtig, vorhersehbare Fehlerbehandlung: Trigger auf SQL Server 2000 und früher verursachte Stapelabbrüche bei Fehler/Rollback, was nicht ideal ist (um es gelinde auszudrücken!). Trigger sind also jetzt zuverlässiger.

Answer 2

Trigger sind automatische Side Effects und werden Sie sicherlich auf der ganzen Linie beißen, wenn Sie etwas tun wollen und kann nicht wegen der Nebenwirkungen der Trigger. Hauptsächlich Dinge wie die Teilnahme Ihres Systems an einigen XA-Transaktionen mit anderen externen Systemen. Auslöser machen das UNMÖGLICH. Es ist auch eine Side-Effect-Logik, die NUR aktiviert werden kann, indem der Trigger-Aktivator erneut ausgeführt wird. Wenn Sie Daten im Warehouse neu erstellen möchten, können Sie nicht einfach eine Prozedur ausführen und neu erstellen, sondern Sie müssen alle Aktivitäten ausführen, die die Trigger auslösen. Dies ist ein Albtraum. INSERT, UPDATES und DELETES sollten idempotent und orthogonal sein. Trigger erschweren unnötigerweise Workflows, auch wenn Sie denken, dass sie sie vereinfachen, sind sie nicht.

Answer 3

Es hängt von Ihren Geschäftsanforderungen ab und davon, wie Ihre Datenbank verwendet wird. Angenommen, es gibt viele Anwendungen und viele Importe, die sich auf die Tabelle auswirken (wir haben Hunderte von Dingen, die unsere Tabellen beeinflussen können). Angenommen, es gibt auch gelegentlich die Notwendigkeit, Abfragen zu schreiben, die von SSMS (ja, sogar auf Prod) ausgeführt werden, um beispielsweise alle Preise um 10% zu aktualisieren. Wenn Sie diese Art von Dingen tun, dann ist ein gespeicherter Prozess unpraktisch, Sie werden nie alle möglichen Möglichkeiten haben, die betroffene Datenbank zu beeinflussen.

Wenn diese Datenänderung für die Datenintegrität erforderlich ist oder viele Anwendungen oder Prozesse (Importe, SQL Server-Jobs usw.) Daten beeinflussen können, gehört sie in den Trigger.

Wenn die Datenänderung nur manchmal benötigt wird oder Sie die vollständige Kontrolle darüber haben, wie Daten von nur einer Anwendung geändert werden, ist ein gespeicherter proc in Ordnung.