SQL-Trigger und wann oder wann sie nicht verwendet werden sollen.

Als ich ursprünglich etwas über SQL lernte, wurde mir immer gesagt, dass ich Trigger nur dann verwenden soll, wenn Sie wirklich gespeicherte Prozeduren verwenden müssen, wenn dies möglich ist.

Leider war ich damals (vor ein paar Jahren) nicht so neugierig und kümmerte mich um die Grundlagen, wie ich es jetzt bin. Deshalb habe ich nie nach dem Grund gefragt, warum.

Wie ist die Meinung der Community dazu? Ist es nur eine persönliche Präferenz von jemandem oder sollten Trigger vermieden werden (genau wie Cursor), es sei denn, es gibt einen guten Grund für sie.

Der Wikipedia-Artikel zu Datenbank-Triggern bietet einen guten Überblick darüber, was Trigger sind und wann sie in verschiedenen Datenbanken verwendet werden sollen.

Die folgende Diskussion basiert nur auf SQL Server.

Die Verwendung von Triggern ist sinnvoll, wenn ihre Verwendung gerechtfertigt ist. Zum Beispiel haben sie einen guten Wert bei der Prüfung (Aufrechterhaltung des Datenverlaufs), ohne expliziten Prozedurcode für jeden CRUD-Befehl in jeder Tabelle zu benötigen.

Trigger geben Ihnen die Kontrolle, unmittelbar bevor Daten geändert werden und unmittelbar nachdem die Daten geändert wurden. Dies ermöglicht:

• Prüfung wie zuvor erwähnt
• Validierung und Überprüfung der Unternehmenssicherheit, falls gewünscht. Aufgrund dieser Art der Steuerung können Sie Aufgaben wie das Formatieren von Spalten vor und nach dem Einfügen in die Datenbank ausführen.

Mir wurde immer gesagt, dass Sie Trigger nur verwenden sollten, wenn Sie wirklich gespeicherte Prozeduren verwenden möchten, wenn dies möglich ist.

Dies kann unter anderem folgende Gründe haben:

1. Einige Funktionen, die früher ausgeführt wurden, konnten jetzt auf andere Weise ausgeführt werden, z. B. die Aktualisierung von Summen und die automatische Berechnung für eine Spalte.
2. Sie können nicht erkennen, wo der Trigger aufgerufen wird, indem Sie den Code allein untersuchen, ohne zu wissen, dass er vorhanden ist. Sie sehen ihre Auswirkung, wenn Sie die Datenänderungen sehen, und es ist manchmal rätselhaft herauszufinden, warum die Änderung stattgefunden hat, es sei denn, Sie wissen, dass es einen Auslöser oder mehr gibt, der auf die Tabelle (n) einwirkt.
3. Wenn Sie mehrere Datenbanksteuerelemente wie CHECK, RI, Trigger für mehrere Tabellen verwenden, wird der detaillierte Transaktionsfluss zu verstehen und zu verwalten komplex. Sie müssen genau wissen, was wann passiert. Auch hierfür benötigen Sie eine gute Dokumentation.

Einige Unterschiede zwischen Triggern und gespeicherten Prozeduren ohne Trigger sind (unter anderem):

• Eine gespeicherte Prozedur ohne Trigger ähnelt einem Programm, das explizit entweder über Code oder einen Scheduler oder über einen Batch-Job usw. aufgerufen werden muss, um seine Arbeit zu erledigen, während ein Trigger eine spezielle gespeicherte Prozedur ist, die als eine ausgelöst wird Reaktion eines Ereignisses, anstatt direkt vom Benutzer ausgeführt zu werden. Das Ereignis kann beispielsweise eine Datenänderung in einer Datenspalte sein.
• Trigger haben Typen. DDL-Trigger und DML-Trigger (von Typen: STATT, Fuer und NACHHER)
• Nicht ausgelöste gespeicherte Prozeduren können auf jeden Objekttyp verweisen. Um jedoch auf eine Ansicht zu verweisen, müssen Sie INSTEAD OF-Auslöser verwenden.
• In SQL Server können Sie für gespeicherte Prozeduren, die keine Trigger sind, eine beliebige Anzahl angeben, jedoch nur 1 STATT DES Triggers pro Tabelle.

Trigger sind eine Voraussetzung für komplexe Datenintegritätsregeln. Diese können nur in der Datenbank erzwungen werden, da sonst Probleme mit der Datenintegrität auftreten.

Sie sind auch der beste Ort für die Überwachung, es sei denn, Sie möchten nicht alle Änderungen an der Datenbank erfassen (dies ist das Problem der Überwachung über die Anwendung).

Trigger können zu Leistungsproblemen führen, wenn sie nicht sorgfältig geschrieben werden und wenn nicht genügend Entwickler über ausreichende Kenntnisse verfügen, um sie gut zu schreiben. Dies ist ein Teil dessen, wo sie ihren schlechten Ruf bekommen.

Trigger sind häufig langsamer als andere Mittel zur Aufrechterhaltung der Datenintegrität. Wenn Sie also eine Prüfbedingung verwenden können, verwenden Sie diese anstelle eines Triggers.

Es ist einfach, schlechte Trigger zu schreiben, die dumme Dinge tun, wie beispielsweise den Versuch, E-Mails zu senden. Möchten Sie wirklich nicht in der Lage sein, Datensätze in der Datenbank zu ändern, wenn der E-Mail-Server ausfällt?

In SQL Server verarbeiten Trigger einen Stapel von Datensätzen. Nur allzu oft denken Entwickler, dass sie nur einen Datensatz einfügen, aktualisieren oder löschen müssen. Dies ist nicht die einzige Art von Datenänderungen, die an einer Datenbank vorgenommen werden. Alle Trigger sollten unter den Bedingungen einer Datensatzänderung und vieler Datensatzänderungen getestet werden. Wenn Sie den zweiten Test nicht durchführen, kann dies zu einer extrem schlechten Leistung der Trigger oder zu einem Verlust der Datenintegrität führen.

Verwendung von Datenbank-Triggern

1. Spaltenwerte automatisch steuern
2. Komplexe Integritätsbedingungen durchsetzen.
3. Komplexe Geschäftsregeln durchsetzen.
4. So passen Sie komplexe Sicherheitsberechtigungen an
5. So pflegen Sie Replikationstabellen
6. Datenänderung prüfen.

Ein anderer Anwendungsfall, auf den ich persönlich gestoßen bin, betrifft Datenbanken, auf die von mehr als einem Programm zugegriffen wird. Wenn Sie Funktionen implementieren, aber nicht alle Systeme neu entwerfen möchten, ist ein Trigger eine sinnvolle Lösung.

Ich habe zum Beispiel kürzlich an einer Datenbank gearbeitet, die zuvor nur als Office-System existierte. Als eine Webanwendung geschrieben wurde, um mit ihr zu kommunizieren, wollten wir ein Benachrichtigungssystem implementieren (ähnlich wie zum Beispiel stackexchange), das von mehreren Ereignissen wie der Verarbeitung einer Transaktion usw. ausgelöst wird. Wir konnten einen Trigger implementieren, sodass Updates im Office-Backend einen Trigger auslösten, um die Benachrichtigung für das Frontend zu erstellen und dem Benutzer mitzuteilen, dass ihre Transaktion vom Office verarbeitet wurde.

Trigger können verwendet werden, um Einschränkungen für die Datenbank zu erzwingen, die während der Erstellung des Datenbankschemas und aller DML-Anweisungen nicht erzwungen werden können.

Nehmen wir an, Sie müssen Daten nahezu in Echtzeit auf ein Drittanbieter-System übertragen. Ihre Tabelle enthält 950 Gigabyte an Daten. Es ist also zu groß, um einfach die gesamte Tabelle auf die App eines Drittanbieters zu übertragen.

Stattdessen sammeln Sie Änderungen in einer Warteschlange. Einige externe Programme senden dann in regelmäßigen Abständen kleine Stapel von Daten aus der Warteschlange.

Das System verfügt über mehr als 2000 gespeicherte Prozeduren. Sie wissen auch, dass im Quellcode Tonnen von SQL vorhanden sind. Um sicherzustellen, dass die Warteschlange korrekt gefüllt ist, müssen Sie alle gespeicherten Prozesse und Codes durchsuchen und hoffen, dass Sie nichts verpassen.

Stattdessen können Sie einen Trigger in die Tabelle einfügen, um die Warteschlange auf dem neuesten Stand zu halten. Verpassen Sie garantiert nichts. Ein zentraler Ort. Leistungsstrafe? Nicht wirklich, weil der Treffer beim Auffüllen der Warteschlange nicht vermieden werden kann, egal ob es sich um einen Trigger oder einen externen handelt.

In diesem Szenario würde ich sagen, dass die Verwendung eines Triggers keine schlechte Wahl für das Design ist. Wenn Sie später eine neue Methode zum Übertragen von Daten verwenden möchten (z. B. dass die Warteschlange nicht funktioniert) und die Benutzeroberfläche sich ändert, sind Sie geschützt, wenn Sie den Auslöser verwenden. Trigger sind oft die beste Wahl. Hören Sie nicht auf dogmatische Anti-Trigger-Fanboys.

Ein Auslöser, der E-Mails sendet, ist nicht unbedingt eine „blöde“ Idee. Was dumm ist, ist, den E-Mail-Ausfall im Entwurf nicht zu antizipieren und ihn ohne Datenverlust ordnungsgemäß zu handhaben. Der "blöde" Teil davon ist wirklich schlecht für die nicht existierende Fehlerbehandlung durch faule Entwickler, die das Gefühl haben, immun gegen Fehler zu sein.

Ich möchte auch die Beobachtung anbieten, dass ein Trigger einfach gehalten werden kann, indem eine gespeicherte Prozedur / Funktion aufgerufen wird, die willkürlich kompliziert sein kann und durch mehrere Trigger oder andere gespeicherte Prozeduren wiederverwendbar sein kann. Deshalb gibt es Pakete und Bibliotheken.

Bigotterie ist wirklich lähmend.