<\/p>\n
„Trigger oder nicht Trigger. Das ist hier die Frage.“, wäre wohl die Aussage von Hamlet gewesen, hätte er sich mit Datenbankentwicklung und nicht mit anderen Tragödien beschäftigt. Eine Entscheidung für oder gegen Trigger ist selten unstrittig. Die IT-Branche ist nicht gerade arm, was Grundsatzdiskussionen und Glaubenskriege angeht. Und so hat auch die Datenbankentwicklung ein immer wiederkehrendes Thema: Pro und Contra Trigger. Dies soll nun kein einsamer Monolog für oder gegen Trigger werden, sondern die grundsätzliche Funktionsweise von Triggern erklären und Ihnen einige Informationen liefern, auf deren Grundlage Sie Ihre eigene Meinung bilden können.<\/b><\/p>\n
Trigger können wie gespeicherte Prozeduren mehrere SQL-Anweisungen enthalten und werden als Objekt zur wiederverwendbaren Ausführung im SQL Server gespeichert. Wie auch bei einer gespeicherten Prozedur wird für einen Trigger bei der ersten Ausführung ein Ausführungsplan erstellt und im Prozedurcache abgelegt. Bei der nächsten Ausführung entfällt die Erstellung des Ausführungsplans, da der im Prozedurcache gespeicherte wiederverwendet werden kann. Insofern nutzen Trigger dieselben Performancevorteile wie gespeicherte Prozeduren.<\/p>\n
Hier enden bereits die Gemeinsamkeiten von gespeicherten Prozeduren und Triggern, denn im Gegensatz zu gespeicherten Prozeduren sind Trigger keine eigenständigen Objekte und können nicht manuell aufgerufen werden. Vielmehr werden die im Trigger gespeicherten SQL-Anweisungen als fester Bestandteil einer Tabelle gespeichert.<\/p>\n
Einsatzmöglichkeiten von Triggern<\/p>\n
Ein Trigger ist immer an eine Tabelle gebunden und wird nur über eine Datenmanipulation – ein Update<\/b>, ein Insert<\/b> oder ein Delete<\/b> – an dieser Tabelle ausgelöst. <\/p>\n
Durch diesen Automatismus eignen Trigger sich besonders zur Gewährleistung der Datenkonsistenz und der Einhaltung von Geschäftsregeln. <\/p>\n
Nachfolgend einige Beispiele für den Einsatz von Triggern:<\/p>\n
Dies sind nur ein paar Beispiele für den Einsatz von Triggern. Dadurch, dass Sie bis auf wenige Ausnahmen dieselben Möglichkeiten wie bei gespeicherten Prozeduren haben, können Sie mit Triggern sehr viel Logik abbilden. Um einen Trigger zu verwenden, muss dieser zunächst programmiert werden. Wie bereits erwähnt, wird ein Trigger immer dann ausgeführt, wenn an einer Tabelle Daten manipuliert wurden. Aus diesem Grund ist der Quellcode eines Triggers immer fest mit einer Tabelle verbunden.<\/p>\n
Zu einem Trigger gehört nicht nur die Angabe der Tabelle, sondern auch die Aktion der Datenmanipulation. Ein Trigger reagiert nicht zwangsläufig bei allen Datenmanipulationen, sondern auf solche, für die er auch definiert wurde.<\/p>\n
Dabei kann der Trigger nur für eine der drei Aktionen Insert, Delete, Update oder für eine Kombination der drei aktiv werden. Die automatische Ausführung (im Fachjargon „das Feuern“) des Triggers ist nur bei diesen drei Aktionen möglich. Für andere Aktionen der Tabelle, wie Truncate Table, kann kein Trigger definiert werden.<\/p>\n
Einer Tabelle können mehrere Trigger anhaften. Es können mehrere Aktionen in einem Trigger behandelt, pro Aktion ein einzelner Trigger und auch mehrere Trigger für eine einzelne Aktion erstellt werden. Es wäre also etwa möglich, für eine Tabelle einen Trigger zu definieren, der nur auf die Aktion Delete <\/b>reagiert, und noch einen Trigger, der die Aktionen Insert <\/b>und Update <\/b>behandelt. Hinzu käme noch ein Trigger für einen besonderen Fall einer Update-Anweisung, der speziell nur dafür eingesetzt wird. <\/p>\n
Sofern Sie für eine Aktion mehrere Trigger definiert haben, müssen Sie zusätzlich noch die Reihenfolge der Ausführung der Trigger mit der Systemprozedur sp_settriggerorder <\/b>festlegen.<\/p>\n
Der Trigger selbst enthält verschiedene Prüfungen und Anweisungen. Diese Prüfungen und Anweisungen programmieren Sie in T-SQL. Im Großen und Ganzen kann man die Entwicklung von Triggern mit der Entwicklung von gespeicherten Prozeduren vergleichen. Bei der Programmierung muss jedoch beachtet werden, dass die SQL-Anweisungen immer pro Aktion der Datenmanipulation ausgeführt werden. Insofern sollten auch alle betroffenen Datensätze der Datenmanipulation im Trigger angesprochen werden.<\/p>\n
Diese Datensätze stehen innerhalb des Triggers in den virtuellen Tabellen inserted <\/b>und deleted <\/b>zur Verfügung. Beide Tabellen besitzen dieselbe Struktur wie die Tabelle des Triggers. Die Tabelle inserted <\/b>beinhaltet die neuen Datensätze, die durch eine INSERT<\/b>-Anweisung der Tabelle hinzugefügt wurden, während die Tabelle deleted <\/b>die durch eine DELETE<\/b>-Anweisung gelöschten Datensätze enthält. Die UPDATE<\/b>-Anweisung nutzt beide Tabellen: die Werte vor der änderung stehen in der Tabelle deleted <\/b>und die Werte nach der änderung in der Tabelle inserted<\/b>.<\/p>\n
Beide Tabellen können innerhalb des Triggers wie SQL Server-Tabellen verwendet werden. Sie können die Daten der Tabellen aggregieren, filtern, sortieren und die Tabellen mit anderen Tabellen verknüpfen und vieles mehr. Nur ändern können Sie die Daten dieser Tabellen nicht.<\/p>\n
Trigger sind neben gespeicherten Prozeduren die einzigen SQL Server-Objekte, mit denen Daten manipuliert werden können. Es ist also möglich, in einem Trigger selbst wieder die Befehle Update<\/b>, Delete <\/b>und Insert <\/b>zu verwenden.<\/p>\n
Diese können Sie in der Tabelle des Triggers wie auch in anderen Tabellen ausführen. Sie sollten aber bedenken, dass durch diese Datenmanipulationen ebenfalls wieder Trigger ausgelöst werden können, die wiederum durch eigene Datenmanipulationen Trigger auslösen können.<\/p>\n
Schließlich ist es sogar möglich, dass der Trigger, der die Datenmanipulation ausführt, durch weitere Trigger nochmals ausgelöst wird. Solche rekursiven Aufrufe sind in einer Tiefe von bis zu 32 Ebenen möglich. Diese Rekursivität wird nicht standardmäßig unterstützt, sondern muss in den Optionen der Datenbank erst aktiviert werden.<\/p>\n
Mit Triggern können Sie die manipulierten Daten prüfen und je nach Ergebnis der Prüfung die Manipulation auch verhindern. Um dies dem Benutzer gegenüber transparent zu gestalten, können Sie aus einem Trigger heraus Meldungen ausgeben. <\/p>\n
Neben der Ausgabe von Meldungen kann ein Trigger auch noch Daten ausgeben. Was auf den ersten Blick vielleicht selbstverständlich klingt, ist auf den zweiten eher fragwürdig. Denn welche Daten sollte ein Trigger liefern und, vor allem, wohin? Schließlich wird der Trigger bei einer Datenmanipulation an einer Tabelle automatisch ausgeführt und nicht im direkten Kontext einer manuellen Ausführung oder über ein Frontend. Ein wichtiger Punkt wurde bisher noch nicht erwähnt: Der SQL Server bietet zwei Arten von Triggern – den AFTER<\/b>-Trigger und den INSTEAD OF<\/b>-Trigger.<\/p>\nAFTER-Trigger<\/h2>\n
Ein AFTER<\/b>-Trigger – früher auch als FOR<\/b>-Trigger bekannt – wird erst nach der Datenmanipulation ausgelöst. Die im Trigger gespeicherten SQL-Anweisungen ergänzen somit die eigentliche Datenmanipulation.<\/p>\n
Doch bis zur Ausführung des AFTER<\/b>-Triggers ist es erst einmal ein weiter Weg. Der Vorgang einer Datenmanipulation teilt sich in mehrere Schritte:<\/p>\n Ein AFTER<\/b>-Trigger wird also nicht immer zwangsläufig ausgeführt, denn dazu ist die erfolgreiche Verarbeitung der eigentlichen Datenmanipulation eine unabdingbare Voraussetzung. Dadurch ist der AFTER<\/b>-Trigger – wie der Name schon sagt – prädestiniert für Aktionen, die nach der vorhergehenden Datenmanipulation folgen müssen.<\/p>\n Mögliche Funktionen von AFTER<\/b>-Triggern wären etwa die Protokollierung von Datenänderungen oder die Gewährleistung der Datenkonsistenz bei redundanter Datenhaltung, da hier nach der eigentlichen Datenmanipulation eine weitere ausgeführt wird.<\/p>\n Ein INSTEAD OF<\/b>-Trigger hingegen greift vor der eigentlichen Datenmanipulation ein und ist eher für die Vermeidung oder Korrektur einer solchen zuständig.<\/p>\n Während der AFTER<\/b>-Trigger am Ende der einzelnen Schritte einer Datenmanipulation steht, folgt der INSTEAD OF<\/b>-Trigger als zweiter Schritt direkt hinter der Erstellung der Tabellen inserted <\/b>und deleted<\/b>.<\/p>\n Dies ist notwendig für die grundsätzlichen Aufgaben eines INSTEAD OF<\/b>-Triggers: Das Prüfen der Datenmanipulation und das damit verbundene Verhindern der Aktion oder das Ersetzen der Werte durch andere, korrekte Werte. Insofern ist ein INSTEAD OF<\/b>-Trigger optimal für die Prüfung von Dateneingaben, das Durchsetzen der referentiellen Integrität, das Erstellen von komplexen Standardwerten oder die Prüfung von aufwendigen Einschränkungen.<\/p>\n Ein INSTEAD OF<\/b>-Trigger erweitert also nicht den Vorgang der eigentlichen Datenmanipulation, sondern ersetzt diesen durch seine eigenen SQL-Anweisungen. Für die Datenmanipulation ist nun nicht mehr die eigentliche Aktion mitsamt den dort geänderten Daten maßgebend, sondern die SQL-Anweisungen im INSTEAD OF<\/b>-Trigger.<\/p>\n Im Gegensatz zu einem AFTER<\/b>-Trigger können Sie pro Update<\/b>, Delete <\/b>oder Insert <\/b>nur einen INSTEAD OF<\/b>-Trigger definieren. Neben dem Ausführungszeitpunkt ist dies auch schon der einzige Unterschied zum AFTER<\/b>-Trigger. Die Entwicklung beider Typen ist identisch.<\/p>\n Für die Schreiben eines Triggers kann das SQL Server Management Studio verwendet werden. Die Trigger einer Tabelle finden Sie unterhalb der jeweiligen Tabelle im Knoten Trigger<\/b>. Dort sehen Sie im Kontextmenü auch den Eintrag Neuer Trigger<\/b> zum Anlegen eines neuen Triggers (s. Abb. 1).<\/p>\n Abb. 1: Ein neuer Trigger<\/p>\n Das SQL Server Management Studio bietet Ihnen zur Erstellung eines Triggers keinen Abfragedesigner. Wie schon bei den gespeicherten Prozeduren erhalten Sie lediglich ein neues Abfragefenster mit einer Skriptvorlage; in diesem Fall mit einer Vorlage zur Anlage eines neuen Triggers.<\/p>\n Einen neuen Trigger legen Sie mit der Anweisung CREATE TRIGGER <\/b>an. Dazu müssen Sie nicht nur den Namen des Triggers angeben, sondern mit der Option ON <\/b>auch <\/b>die Tabelle, an die dieser Trigger gebunden ist. Als weitere Voraussetzung müssen der Typ – AFTER <\/b>oder INSTEAD OF<\/b> -, sowie die Aktion(en) Insert<\/b>, Delete<\/b> oder Update<\/b> angegeben werden.<\/p>\n Anschließend wird die eigentliche Programmlogik durch AS <\/b>eingeleitet und im BEGIN…END<\/b>-Block zusammengefasst. Dort können Sie Ihren Ideen freien Lauf lassen, sofern diese nicht gegen die Regeln von T-SQL verstoßen oder der Logik der Trigger-Entwicklung widersprechen.<\/p>\n Den ersten T-SQL-Befehl in Ihrem Trigger bietet Ihnen die Vorlage auch schon direkt an: SET NOCOUNT ON<\/b>. Sie sollten dieses Angebot unbedingt annehmen, da diese Anweisung die Ausgabe der Meldungen xx rows affected<\/b> zu den DONE_IN_PROC<\/b>-Anweisungen unterbindet. Access hat je nach Version und eingesetztem Treiber mit diesen Rückmeldungen so seine Probleme. Doch dazu später mehr.<\/p>\n Als Erstes lernen Sie die Umsetzung eines klassischen AFTER<\/b>-Triggers kennen: Die in der Northwind<\/b>-Datenbank vergebenen Rabatte von 10 bis 25 Prozent bei den Bestellpositionen sollen in einer eigenen Tabelle protokolliert werden.<\/p>\n Diese Tabelle wird den Abteilungsleitern als Grundlage zu Auswertungen dienen. Um ihnen die Auswertung etwas zu erleichtern, werden die Bestellnummer, Kundennummer, Artikelnummer, Einzelpreis, Menge und Rabatt, sowie die Mitarbeiter-ID des Verkäufers und die Mitarbeiter-ID des Vorgesetzten in der Tabelle protokolliert. <\/p>\n Doch vorab benötigen Sie für dieses Beispiel noch die Tabelle zur Protokollierung der Daten. Listing 1 zeigt das CREATE TABLE<\/b>-Skript, mit dem Sie diese Tabelle anlegen können.<\/p>\n Listing 1: Tabelle zur Protokollierung<\/p>\n Im Trigger selbst müssen nur die betroffenen Datensätze, also jene mit Rabatten zwischen 10 und 20 Prozent, in die neue Tabelle geschrieben werden. Listing 2 zeigt die SQL-Anweisungen für diese Protokollierung.<\/p>\n Listing 2: Protokollierungs-Trigger<\/p>\n Die Protokollierung besteht aus einer einzigen INSERT<\/b>-Anweisung. Soweit ist der Code des Triggers nichts wirklich Neues für Sie. Aber eine Besonderheit bietet dieser Code dennoch: Im Trigger wird die Funktion Update() <\/b>verwendet.<\/p>\n Mit dieser nur in Triggern verfügbaren Funktion wird geprüft, ob der Wert der dort angegebenen Spalte verändert wurde – vorausgesetzt jedoch, die dort angegebene Spalte befindet sich auch in der manipulierten Tabelle.<\/p>\n Die Existenz der angegebenen Spalte wird nur bei der Ausführung des Triggers geprüft, jedoch nicht beim Anlegen oder ändern des Triggers. Sie sollten also die Schreibweise der Spalte vor dem Speichern des Triggers nochmals genau prüfen.<\/p>\n Einen neuen Trigger speichern Sie durch die Ausführung des Skripts. Für nachträgliche änderungen am Trigger müssen Sie den CREATE TRIGGER<\/b>-Befehl zu einem ALTER TRIGGER <\/b>ändern, da nur mit diesem Befehl bestehende Trigger verändert werden können.<\/p>\n Nach dem Speichern und der Neuanlage des Triggers trg_OrdersLog<\/b> möchten Sie diesen bestimmt testen. Den Trigger können Sie durch das Anlegen eines neuen Datensatzes oder durch das ändern eines bestehenden Datensatzes in der Tabelle Order Details<\/b> auslösen. In beiden Fällen muss zur Protokollierung allerdings ein Discount zwischen 0,10 und 0,25 eingegeben werden.<\/p>\n Die erste SQL-Anweisung, die Sie zum Test eingeben können, legt einen neuen Datensatz in der Tabelle Order Details <\/b>an:<\/p>\n Der AFTER<\/b>-Trigger hat nach diesem Insert dann in der Tabelle OrdersLog<\/b> die erste Protokollierung angelegt. Um es dem Anwender nicht zu einfach zu machen, die Protokollierung zu umgehen, werden auch nachträgliche änderungen an einem Rabatt protokolliert, sofern dieser zwischen 10 und 25 Prozent liegt. <\/p>\n Dies können Sie mit einer Update-Anweisung an dem neu hinzugefügten Datensatz testen:<\/p>\n Auch diese Datenmanipulation wurde in der Tabelle OrdersLog<\/b> protokolliert. Die Einträge werden nach folgender SELECT<\/b>-Anweisung ausgegeben:<\/p>\n In Abb. 2 sehen Sie das Ergebnis dieser Prüfung.<\/p>\n Abb. 2: Die Protokollierung<\/p>\n So weit, so gut. Was aber, wenn der Benutzer nun mehr als 25 Prozent Rabatt gewährt? Einen solchen Rabatt möchte der Abteilungsleiter erst gar nicht in seiner Auswertung sehen, sondern diese Eingabe soll von vornherein vermieden werden. Dafür brauchen Sie keinen Trigger, denn diese Anforderung kann bereits mit einer Einschränkung realisiert werden. <\/p>\n Und wenn diese Regelung nur für Mitarbeiter gilt, nicht aber für den Chef selbst? Für eine solche Anforderung reicht die Funktion einer Einschränkung nicht aus, denn hierzu muss zunächst geprüft werden, ob der Benutzer einfacher Mitarbeiter oder der Chef des Hauses ist. Diese Anforderung kann entweder mit einem AFTER<\/b>-Trigger oder mit einem INSTEAD OF<\/b>-Trigger realisiert werden. <\/p>\n Die Geschäftsregel wird bei einem AFTER<\/b>-Trigger erst nach der bereits durchgeführten Datenmanipulation geprüft. Insofern muss die Aktion bei Verletzen der Regel wieder rückgängig gemacht werden.<\/p>\n Wie auch beim Trigger trg_OrdersLog<\/b> erfolgt die Prüfung nur auf die Spalte Discount<\/b> und auch nur dann, wenn sich der Wert der Spalte verändert hat. Der Status des Mitarbeiters wird anhand der Spalte ReportsTo<\/b> in der Tabelle Employees<\/b> ermittelt. Ist diese Spalte leer, gibt es für den entsprechenden Mitarbeiter niemanden, an den er Bericht erstatten muss. Ein Mitarbeiter in einer solchen Position ist meist auch der Chef des Hauses. <\/p>\n Anhand dieser Definition wird nun der maximale Wert der Spalte Discount<\/b> der inserted<\/b>-Tabelle ermittelt. Enthält die Spalte Discount<\/b> nach der änderung einen Wert größer 0,25, wird per RAISERROR <\/b>eine Fehlermeldung ausgegeben (Abb. 3) und die Datenänderungen werden per ROLLBACK wieder auf den Zustand vor der Datenmanipulation gesetzt. <\/p>\n Abb. 3: Trigger in Aktion<\/p>\n Die Umsetzung der Anforderung mit einem AFTER<\/b>-Trigger sehen Sie in Listing 3. <\/p>\n Listing 3: Prüfung per AFTER-Trigger<\/p>\n Bei der Variante mit dem INSTEAD OF<\/b>-Trigger wird kein ROLLBACK <\/b>benötigt, da die Datenmanipulation erst gar nicht ausgeführt wird, wenn die Geschäftsregel nicht eingehalten wurde. <\/p>\n Listing 4 zeigt die Umsetzung der Anforderung mit einem INSTEAD OF<\/b>-Trigger. <\/p>\n Listing 4: Prüfung per INSTEAD OF-Trigger<\/p>\n Auch hier erfolgt die Prüfung der Geschäftsregel in Abhängigkeit davon, ob sich der Wert der Spalte Discount<\/b> durch die Datenmanipulation verändert hat. Der Mitarbeiterstatus wird wie beim AFTER<\/b>-Trigger über die Spalte ReportsTo<\/b> ermittelt. Bei einem Rabatt von mehr als 25 Prozent und der Identifizierung des Benutzers als Mitarbeiter wird der Benutzer zunächst durch eine Fehlermeldung (ausgelöst durch RAISERROR<\/b>) auf die falsche Eingabe hingewiesen (Abb. 3) und danach der Trigger mittels RETURN beendet. <\/p>\n Da ein INSTEAD OF<\/b>-Trigger die eigentliche Datenmanipulation durch eigene Anweisungen ersetzt – was durch Auslösen der Fehlermeldung und Beenden durch Return <\/b>auch erfolgreich umgesetzt wurde – werden keine Datenmanipulationen durchgeführt. Der Versuch, einen höheren Rabatt als 25 Prozent zu erfassen, wurde auf diese Art verhindert.<\/p>\n Das Ersetzen der eigentlichen Datenmanipulation durch eigene SQL-Anweisungen bedeutet aber auch, dass im positiven Fall der Prüfung die eigentliche Datenmanipulation im Trigger nochmals ausgelöst werden muss. Aus diesem Grund muss die Update-Anweisung wie auch der Insert-Befehl für die beiden möglichen Datenmanipulationen im Trigger enthalten sein. Die Werte für die einzelnen Aktionen können aus den Tabellen inserted <\/b>und deleted <\/b>gelesen werden.<\/p>\n Durch den Trigger wird die Datenmanipulation verhindert, sobald die Geschäftsregel verletzt wird. Es gibt an dieser Regel kein Vorbeikommen. Dies gilt für Datenmanipulationen an einzelnen Datensätzen wie auch für Datenmanipulationen mehrerer Datensätze, etwa bei Massenimporten oder Massenänderungen.<\/p>\n Sobald in einem Massenimport oder bei einer Massenänderung in nur einer Bestellposition ein Rabatt von mehr als 25 Prozent gewährt wird, wird der komplette Vorgang mit einem Fehler beendet. Bei einem AFTER<\/b>-Trigger sorgt dann das ROLLBACK <\/b>für das Zurücksetzen der bereits geschriebenen Datenänderungen in den Zustand vor der änderung, während bei einem INSTEAD OF<\/b>-Trigger die eigentliche Datenmanipulation bereits vorher verhindert wird. Dadurch werden leider auch jene Datensätze des Massenimports beziehungsweise der Massenänderung nicht verändert, bei denen die Geschäftsregel durchaus eingehalten wurde.<\/p>\n Um in einem solchen Fall nach der Aschenputtel-Methode („die Guten ins Töpfchen, die Schlechten ins Kröpfchen“) zu verfahren, sprich: die Datensätze zu verarbeiten, die den Geschäftsregeln entsprechen, und nur die Datenmanipulationen zu verhindern, die gegen die Regel verstoßen, muss die Verarbeitung im Trigger erweitert werden, indem jeder einzelne Datensatz der inserted<\/b>-Tabelle geprüft wird.<\/p>\n Eine solche Prüfung ist nur in einem INSTEAD OF<\/b>-Trigger möglich. Nur dort können die „guten“ von den „schlechten“ Datensätzen vorab über eine IF<\/b>-Anweisung getrennt werden. Wobei die „Guten“ ins Töpfchen, also in die Tabelle, geleitet und die „Schlechten“ ins Kröpfchen, etwa in eine Protokolldatei, gelegt werden könnten. Eine solche Einzelverarbeitung wirkt sich natürlich negativ auf die Performance der Datenverarbeitung aus.<\/p>\n Mit einem AFTER<\/b>-Trigger ist eine solche Trennung nicht realisierbar, da er die Geschäftsregel erst nach der Datenmanipulation prüft. Ein dann ausgelöstes ROLLBACK <\/b>gilt für alle Datensätze. Ein ROLLBACK <\/b>für einzelne Datensätze ist nicht möglich.<\/p>\n Sie sehen, es gibt unterschiedliche Einsatzmöglichkeiten für die beiden Trigger-Typen. Welchen Trigger-Typ Sie für welches Szenario einsetzen, kommt auf die jeweilige Anforderung an. <\/p>\n An dieser Stelle sei noch ein weiterer Trigger-Typ erwähnt, der im Zusammenhang mit dem SQL Server immer wieder genannt wird: Der BEFORE<\/b>-Trigger. Dieser Beitrag enthält aber weder eine Beschreibung, noch ein Skript zum Thema BEFORE<\/b>-Trigger. Ganz einfach: Der SQL Server bietet keine BEFORE<\/b>-Trigger. Mit BEFORE<\/b>-Triggern beim MS SQL Server verhält es sich wie mit dem Yeti im Himalaya. Es wird immer mal wieder behauptet, dass es ihn gibt, aber gesehen hat ihn noch keiner.<\/p>\n Auf den ersten Blick scheinen Trigger durch die automatisierte Ausführung die erste Wahl bei der Datenbankentwicklung zu sein. Immerhin können Sie hier die Regeln der Geschäftslogik und der Datenkonsistenz fest an Tabellen und die jeweiligen Aktionen der Datenmanipulationen binden. Doch wie eingangs erwähnt, ist der Einsatz von Triggern immer wieder Bestandteil diverser Diskussionen – zu Recht.<\/p>\n Die eben erwähnte Einhaltung der technischen Geschäftsregeln und die Sicherstellung der Datenkonsistenz sind auch ein Argument für Trigger. <\/p>\n In manchen Fällen können Trigger sogar die einzige Chance sein, diese Anforderungen in einer Datenbank umzusetzen. Besonders dann, wenn Sie keine Möglichkeit haben, in diese Datenbank gespeicherte Prozeduren aufzunehmen. Denn auch mit gespeicherten Prozeduren können Sie – wie im vorangegangenen Artikel dieser Serie beschrieben – die Datenkonsistenz gewährleisten und die Geschäftslogik abbilden. <\/p>\n Stellen Sie sich das Gesicht eines Projektleiters vor, dem Sie zur Vermeidung von Dateninkonsistenzen die Kapselung jeder Geschäftslogik in gespeicherten Prozeduren vorschlagen. Es müssten pro Tabelle verschiedene gespeicherte Prozeduren programmiert werden und auch das Frontend müsste dementsprechend angepasst werden. Dieser recht große Aufwand kann durch den Einsatz von Triggern minimiert werden.<\/p>\n Doch nur in solchen Situationen sind Trigger den gespeicherten Prozeduren vorzuziehen. Sobald Sie die Möglichkeit haben, die Regeln zur Geschäftslogik und Datenkonsistenz in gespeicherten Prozeduren abzubilden, sollten Sie diese Möglichkeit nutzen und auf Trigger verzichten. Der Einsatz von gespeicherten Prozeduren ist weitaus effektiver.<\/p>\n Dies ist nicht nur in der flexibleren Art und in umfangreicheren Möglichkeiten zur Programmierung begründet, sondern auch in der Chance, die Regeln und Algorithmen zur Verwaltung der Daten einer oder mehrerer Tabellen in einer gespeicherten Prozedur zu kapseln. Der Code zur Einhaltung der Datenkonsistenz und der Geschäftslogik liegt in einem einzigen Objekt – der gespeicherten Prozedur – und ist somit leichter zu pflegen.<\/p>\n Keine der anfangs erwähnten Einsatzmöglichkeiten eines Triggers kann nicht auch mit einer gespeicherten Prozedur realisiert werden: Die Bildung von Summen als redundante Datenhaltung lässt sich beim ändern der Positionssätze ermitteln und innerhalb einer Transaktion direkt im Rechnungskopf verändern, Standardwerte können aus anderen Tabellen abgeleitet und als Konstanten in der SQL-Anweisung übergeben werden, Protokollierungen von Datenmanipulationen können mit einer Transaktion umgesetzt werden, die die SQL-Anweisung der jeweiligen Datenmanipulation wie auch die SQL-Anweisung zur Protokollierung in einer anderen Tabelle enthält, und Dateneingaben können vor der Datenmanipulation geprüft und gegebenenfalls vermieden werden. <\/p>\n Sogar die Daten der Tabellen inserted <\/b>und deleted <\/b>können Sie ab dem SQL Server 2005 in einer gespeicherten Prozedur verwenden. Schauen Sie sich in der Hilfe (BOL) einfach mal den Befehl OUTPUT <\/b>an.<\/p>\n In den gespeicherten Prozeduren haben Sie nicht nur mehr Möglichkeiten zur Programmierung, auch die Pflege gestaltet sich leichter. Durch den Umstand, dass Trigger immer fest mit einer Tabelle verbunden sind, müssen Sie wissen, an welcher Tabelle welche Trigger definiert sind.<\/p>\n Das SQL Server Management Studio bietet Ihnen keine tabellenübergreifende Übersicht aller Trigger. Dies sieht bei den gespeicherten Prozeduren anders aus. In der Datenbank gibt es unter dem Knoten Programmierbarkeit <\/b>einen eigenen Zweig namens Gespeicherte Prozeduren<\/b>. Dort sind alle gespeicherten Prozeduren Ihrer Datenbank zu finden.<\/p>\n Auch die Fehlersuche gestaltet sich mit gespeicherten Prozeduren einfacher. Durch den Quellcode im Frontend wie auch im SQL Server sind die Aufrufe der gespeicherten Prozeduren direkt zu erkennen. Ein Trigger jedoch ist im Quellcode nicht zu finden, da er ja nicht manuell ausgeführt wird. Trigger sind nicht transparent und werden bei einer Fehlersuche meist erst als letzte Ursache in Betracht gezogen. Dies kann die Suche nach einem Fehler stark in die Länge ziehen. <\/p>\n Neben den bisher eher konzeptionellen Gründen gibt es auch im Bereich Performance einige Punkte, die gegen den Einsatz von Triggern sprechen. Microsoft weist in den BOL explizit darauf hin, dass ein inflationärer Gebrauch von Triggern das Datenbanksystem durchaus verlangsamen kann. Trigger eskalieren leicht zur Performance-Bremse. <\/p>\n Die Empfehlung in den BOL geht so weit, „die in den Tabellendefinitionen vorhandenen Möglichkeiten, wie referentielle Integrität, Standardwerte und Einschränkungen, für die Einhaltung der Datenkonsistenz und Geschäftsregeln zu nutzen, bevor man den Einsatz eines Triggers in Betracht zieht. Ein Trigger sollte erst dann genutzt werden, wenn die in den Tabellendefinitionen vorhandenen Möglichkeiten für Ihre Anforderungen nicht mehr ausreichen“. <\/p>\n Der Grund für die schlechte Performance liegt in der Architektur von Triggern. Trigger werden bei jeder Datenmanipulation ausgelöst. Sofern sich die SQL-Anweisungen im Trigger nicht direkt auf die temporären Tabellen inserted <\/b>und deleted <\/b>beziehen, werden diese Anweisungen nur einmal pro Aktion ausgeführt. Anweisungen, die sich auf die Tabellen inserted <\/b>und deleted <\/b>beziehen, werden pro geändertem Datensatz ausgeführt. Dies wirkt sich gerade bei Massenimporten negativ auf die Performance aus.<\/p>\n Stellen Sie sich einen täglichen Import von mehreren tausend Bestellungen mit durchschnittlich 20 bis 50 Bestellpositionen in die Datenbank Northwind <\/b>vor. Pro Bestellposition würden die beiden Beispiel-Trigger trg_OrdersLog<\/b> und trg_Discount<\/b> ausgelöst.<\/p>\n Die darin enthaltenen Prüfungen werden unerbittlich ausgeführt, was Zeit kostet und den Massenimport verlangsamt. Natürlich könnten Sie für einen solchen Import die Trigger deaktivieren, aber dann hätten Sie eventuell auch Bestellpositionen mit einem Rabatt größer 25 Prozent oder Rabatten zwischen 10 und 25 Prozent, ohne dass diese protokolliert wurden.<\/p>\n Die definierte Geschäftsregel rund um den Rabatt würde an dieser Stelle nicht greifen. Der Import mitsamt der Prüfung dieser Geschäftsregel wäre mit einer gespeicherten Prozedur eleganter und bei weitem schneller. <\/p>\n Aber auch außerhalb des SQL Servers kann es einige Gründe gegen Trigger geben. Gerade bei Access sorgen Trigger immer wieder für Überraschungen. <\/p>\n Auch wenn es bereits indirekt erwähnt wurde, sollen hier der Vollständigkeit halber noch Verwendungsmöglichkeiten von Triggern unter Access aufgezählt werden. Es ist schlicht so: Es gibt keine. <\/p>\n Ein Trigger wird ja automatisch bei einer Datenmanipulation an einer Tabelle aufgerufen. Ein manueller Aufruf eines Triggers ist weder im SQL Server noch in Access möglich.<\/p>\n Aber gerade diese automatische Ausführung eines Triggers sorgt bei Access immer wieder gerne für Verwirrung. Dies betrifft insbesondere AFTER<\/b>-Trigger, die nach der eigentlichen Datenmanipulation den geänderten Datensatz nochmals ändern.<\/p>\n In Listing 5 sehen Sie den Trigger trg_LastModified<\/b>, der nach einer UPDATE<\/b>-Anweisung an der Tabelle Employees<\/b> die Spalte LastModified<\/b> des geänderten Datensatzes mit dem aktuellen Datum aktualisiert, um den Zeitpunkt der letzten änderung festzuhalten.<\/p>\n Listing 5: Letztes änderungsdatum einstellen<\/p>\n Dieser Trigger wird bei jeder änderung des Datensatzes ausgeführt, sofern der Wert der Spalte LastModified<\/b> nicht geändert wurde. <\/p>\n Der Trigger wird auch dann ausgelöst, wenn Sie den Datensatz in Access ändern. Wenn Sie den Datensatz ein zweites Mal ändern möchten, müssen Sie die Datenanzeige in Access zunächst aktualisieren. Ohne diese Aktualisierung erhalten Sie die Fehlermeldung, dass der Datensatz bereits von einem anderen Benutzer geändert wurde (s. Abb. 4). Dieser andere Benutzer war der Trigger!<\/p>\n Abb. 4: Der Benutzer „Trigger“<\/p>\n Trigger haben noch eine weitere Eigenheit, die für Verwirrung sorgen kann. Die einzelnen SQL-Anweisungen innerhalb eines Triggers lösen immer die bereits erwähnten DONE_IN_PROC<\/b>-Meldungen aus, die an den Client die Information xx rows affected<\/b> übertragen.<\/p>\n Access kann je nach Access-Version und eingesetztem Treiber auf diese Gesprächigkeit mit der Fehlermeldung „Die Schlüsselspalteninformationen sind ungenügend oder inkorrekt. Es sind zu viele Zeilen von der Aktualisierung betroffen“ reagieren. Insofern sollten Sie die DONE_IN_PROC<\/b>-Meldungen im Trigger durch die SQL-Anweisung SET NOCOUNT ON <\/b>unbedingt unterbinden.<\/p>\n Sie sehen, es gibt einige Gründe gegen und einige für Trigger. Letztendlich ist die Entscheidung nicht von der Gesinnung des „Glaubenskriegers“ abhängig, sondern von den Anforderungen des Kunden, die technisch möglichst effizient umgesetzt werden sollen. <\/p>\n Sofern Sie keine gespeicherten Prozeduren einsetzen können oder dürfen, sind Trigger die einzige Chance, die Daten Ihrer Datenbank mit datenbankeigenen Mitteln konsistent zu halten. Bietet sich Ihnen aber die Möglichkeit, die Geschäftsregeln in gespeicherten Prozeduren zu kapseln, sollten Sie diese Methode den Triggern vorziehen. Sie sollten aber auf alle Fälle versuchen, ein Gemisch aus Triggern und gespeicherten Prozeduren zu vermeiden, denn damit machen Sie sich über kurz oder lang nur das Leben schwer.<\/p>\n Enthaltene Beispieldateien:<\/p>\n Skript 1.sql<\/p>\n Skript 2.sql<\/p>\n Skript 3.sql<\/p>\n Skript 4.sql<\/p>\n Skript 5.sql<\/p>\n\n
INSTEAD OF-Trigger<\/h2>\n
Entwickeln eines Triggers<\/h2>\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Trigger-web-images\/Bild23428_opt.jpeg\")
<\/p>\nCREATE TABLE dbo.OrdersLog\n(\nLdfNr int NOT NULL IDENTITY(1,1),\nController int NOT NULL,\nEmployeeId int NOT NULL,\nCustomerId varchar(5) NOT NULL,\nOrderId int NOT NULL,\nProductId int NOT NULL,\nUnitPrice money,\nQuantity smallint,\nDiscount real\n)<\/pre>\n
ALTER TRIGGER [dbo].[trg_Discount] ON [dbo].[Order Details]\nAFTER UPDATE, INSERT\nAS\nBEGIN\nSET NOCOUNT ON;\nIF UPDATE (Discount)\nBEGIN\nIF (select max(Discount) from inserted inner join\ndbo.orders on inserted.orderid =\ndbo.orders.orderid inner join employees on\ndbo.orders.employeeid = dbo.employees.employeeid\nwhere reportsto is not null) > '0.25'\nBEGIN\nRAISERROR (N'Es darf maximal ein Rabatt\nvon 0.25 gewährt werden!',10,1);\nROLLBACK TRAN\nEND\nEND\nEND;<\/pre>\n
INSERT INTO dbo.[Order Details]\nVALUES(11077, 77, €š6.5€, 5, €š0.14€)<\/pre>\n
UPDATE dbo.[Order Details] SET Discount = €š0.14€ WHERE OrderId = 11077 AND ProductId = 77<\/pre>\n
SELECT * FROM dbo.OrdersLog<\/pre>\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Trigger-web-images\/Bild23435_opt.jpeg\")
<\/p>\n![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Trigger-web-images\/Bild23456_opt.jpeg\")
<\/p>\nALTER TRIGGER [dbo].[trg_OrdersLog] ON [dbo].[Order Details]\nAFTER UPDATE, INSERT\nAS\nBEGIN\nSET NOCOUNT ON;\nIF UPDATE(Discount)\nBEGIN\nINSERT INTO dbo.OrdersLog\n(Controller, EmployeeId, CustomerId,\nOrderId, ProductId, UnitPrice,\nQuantity, Discount)\nSELECT IsNull(ReportsTo, 0),\ndbo.Orders.EmployeeId, dbo.Orders.CustomerId,\ninserted.OrderId, inserted.ProductId, inserted.UnitPrice,\ninserted.Quantity, inserted.Discount\nFROM inserted\nINNER JOIN dbo.Orders\nON inserted.OrderId = dbo.Orders.OrderId\nINNER JOIN dbo.Employees\nON dbo.Orders.EmployeeId = dbo.Employees.EmployeeId\nWHERE inserted.Discount >= '0.10'\nAND inserted.Discount <= '0.25'\nEND;\nEND;<\/pre>\n
ALTER TRIGGER [dbo].[trg_Discount] ON [dbo].[Order Details]\nINSTEAD OF UPDATE, INSERT\nAS\nBEGIN\nSET NOCOUNT ON;\nIF UPDATE (Discount)\nBEGIN\nIF (select max(Discount) from inserted inner join\ndbo.orders on inserted.orderid = dbo.orders.orderid\ninner join employees on dbo.orders.employeeid =\ndbo.employees.employeeid where reportsto is not\nnull) > '0.25'\nBEGIN\nRAISERROR (N'Es darf maximal ein Rabatt von 0.25\ngewährt werden!',10,1);\nRETURN\nEND\nUPDATE OD SET Discount = i.Discount FROM\ndbo.[Order Details] OD join inserted i\nON OD.OrderId = i.OrderId AND OD.ProductId =\ni.ProductId join deleted d ON OD.OrderId =\ni.OrderId AND OD.ProductId = i.ProductId\nIF @@RowCount = 0\nBEGIN\nINSERT INTO dbo.[Order Details] SELECT *\nFROM inserted i\nEND\nEND\nEND;<\/pre>\n
Pro und Contra<\/h2>\n
Trigger und Access<\/h2>\n
CREATE TRIGGER [dbo].[trg_LastModified] ON [dbo].[Employees]\nAFTER UPDATE, INSERT\nAS\nBEGIN\nSET NOCOUNT ON;\nIF NOT UPDATE(LastModified)\nBEGIN\nUPDATE dbo.Employees\nSET LastModified = getdate()\nWHERE EmployeeId IN (SELECT EmployeeId FROM inserted)\nEND;\nEND;<\/pre>\n
![\"missing](\"..\/fileadmin\/_temp_\/2008_06\/Trigger-web-images\/Bild23463_opt.jpeg\")
<\/p>\nFazit<\/h2>\n
Downloads zu diesem Beitrag<\/h2>\n