it-swarm.com.de

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

Als ich ursprünglich etwas über SQL gelernt habe, wurde mir immer gesagt, dass Sie Trigger nur verwenden sollten, wenn Sie dies wirklich müssen, und wenn möglich, stattdessen gespeicherte Prozeduren verwenden sollten.

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

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

43
John Mitchell

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 durchaus gültig, wenn ihre Verwendung gerechtfertigt ist. Zum Beispiel haben sie einen guten Wert bei der Prüfung (Aufbewahrung des Datenverlaufs), ohne dass bei jedem CRUD-Befehl in jeder Tabelle expliziter Prozedurcode erforderlich ist.

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

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

Mir wurde immer gesagt, verwenden Sie Trigger nur, wenn Sie es wirklich brauchen, und wählen Sie stattdessen gespeicherte Prozeduren, wenn möglich.

Dies können einige der Gründe dafür sein:

  1. Einige Funktionen, die früher bei Triggern verwendet wurden, konnten jetzt auf andere Weise ausgeführt werden, z. B. zum Aktualisieren von Summen und zur automatischen Berechnung einer Spalte.
  2. Sie sehen nicht, wo der Trigger aufgerufen wird, indem Sie Code allein untersuchen, ohne zu wissen, dass er vorhanden ist. Sie sehen ihre Auswirkung, wenn Sie sehen, dass sich die Daten ändern, und es ist manchmal rätselhaft, herauszufinden, warum die Änderung stattgefunden hat, es sei denn, Sie wissen, dass ein oder mehrere Auslöser auf die Tabelle (n) einwirken.
  3. Wenn Sie mehrere Datenbanksteuerelemente wie CHECK, RI, Trigger für mehrere Tabellen verwenden, wird das Verständnis und die Verwaltung Ihres Transaktionsdetailflusses 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 ist wie ein Programm, das explizit entweder aus Code oder einem Scheduler oder aus einem Stapeljob usw. aufgerufen werden muss, um ihre Arbeit zu erledigen, während ein Trigger eine spezielle Art gespeicherter Prozedur ist, die als ausgelöst wird Antwort eines Ereignisses, anstatt direkt vom Benutzer ausgeführt zu werden. Das Ereignis kann beispielsweise eine Änderung von Daten in einer Datenspalte sein.
  • Trigger haben Typen. DDL-Trigger und DML-Trigger (vom Typ: STATT, Für und NACH)
  • Nicht-Trigger Gespeicherte Prozeduren können auf jeden Objekttyp verweisen. Um jedoch auf eine Ansicht zu verweisen, müssen Sie STATT Trigger verwenden.
  • In SQLServer können Sie für gespeicherte Prozeduren ohne Trigger eine beliebige Anzahl festlegen, jedoch nur 1 STATT Trigger pro Tabelle.
32
NoChance

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 nicht genügend Entwickler über ausreichende Kenntnisse verfügen, um sie gut zu schreiben. Dies ist ein Teil davon, wo sie ihren schlechten Ruf bekommen.

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

Es ist einfach, schlechte Auslöser zu schreiben, die dumme Dinge tun, wie 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 werden Trigger für einen Stapel von Datensätzen ausgeführt. 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 auftreten, und alle Trigger sollten unter den Bedingungen einer Datensatzänderung und vieler Datensatzänderungen getestet werden. Das Vergessen des zweiten Tests kann zu extrem schlechten Auslösern oder einem Verlust der Datenintegrität führen.

10
HLGEM

Verwendung von Datenbank-Triggern

  1. Spaltenwerte automatisch steuern.
  2. Durchsetzen komplexer Integritätsbeschränkungen.
  3. Komplexe Geschäftsregeln durchsetzen.
  4. So passen Sie komplexe Sicherheitsberechtigungen an.
  5. So verwalten Sie Replikationstabellen.
  6. Datenänderung überwachen.
4
asha

Ein weiterer Anwendungsfall, auf den ich persönlich gestoßen bin, betrifft Datenbanken, auf die mehr als ein Programm zugreift. Wenn Sie Funktionen implementieren, aber nicht alle Systeme dafür neu gestalten möchten, ist ein Trigger eine sinnvolle Lösung.

Zum Beispiel habe ich kürzlich an einer Datenbank gearbeitet, die zuvor nur als Office-System existiert hatte. Wenn eine Webanwendung als Schnittstelle für sie geschrieben wurde, wollten wir ein Benachrichtigungssystem implementieren (ähnlich wie zum Beispiel Stackexchange), das durch mehrere Ereignisse ausgelöst wird, z. B. durch die Verarbeitung einer Transaktion usw. Wir konnten einen Auslöser implementieren, sodass Aktualisierungen im Office-Backend einen Auslöser auslösten, um die Benachrichtigung für das Frontend zu erstellen und dem Benutzer mitzuteilen, dass seine Transaktion vom Büro verarbeitet wurde.

2
Matt

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.

1
DEEPAK JADGE

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

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

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 auf die Tabelle setzen, um die Warteschlange auf dem neuesten Stand zu halten. Garantiert nichts zu verpassen. Eine zentrale Lage. Leistungsstrafe? Nicht wirklich, weil der Treffer beim Auffüllen der Warteschlange nicht vermieden werden kann, sei es durch Trigger oder extern.

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 Pushen von Daten verwenden möchten (z. B. wenn die Warteschlange nicht funktioniert) und sich die Benutzeroberfläche ändert, sind Sie geschützt, wenn Sie den Trigger verwenden. Trigger sind oft die beste Wahl. Hören Sie nicht auf dogmatische Anti-Trigger-Fanboys.

0
Lord Tydus