Verwenden der Tabellen „inserted“ und „deleted“

  • Artikel

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

DML-Triggeranweisungen verwenden zwei besondere Tabellen: deleted und inserted. SQL Server erstellt und verwaltet diese Tabellen automatisch. Sie können diese temporären, speicherresidenten Tabellen verwenden, um die Auswirkungen bestimmter Datenänderungen zu testen und Bedingungen für DML-Triggeraktionen festzulegen. Das direkte Ändern der Daten in den Tabellen bzw. das Ausführen von Data Definition Language-(DDL-)Vorgängen für die Tabellen, beispielsweise CREATE INDEX, ist nicht möglich.

Grundlegendes zu den Tabellen „inserted“ und „deleted“

In DML-Triggern werden die Tabellen inserted und deleted hauptsächlich für folgende Vorgänge verwendet:

  • Erweitern der referenziellen Integrität zwischen Tabellen.

  • Einfügen oder Aktualisieren von Daten in Basistabellen, die einer Sicht zugrunde liegen.

  • Testen im Hinblick auf Fehler und Ausführen der entsprechenden Vorgänge.

  • Ermitteln des Unterschieds zwischen dem Tabellenstatus vor und nach einer Datenänderung und Ausführen von Aktionen, die auf diesem Unterschied basieren

Die Tabelle deleted speichert Kopien der betroffenen Zeilen in der Triggertabelle, bevor sie durch eine DELETE- oder UPDATE-Anweisung geändert wurden. Die Triggertabelle ist die Tabelle, in der der DML-Trigger ausgeführt wird. Während der Ausführung einer DELETE- oder UPDATE-Anweisung werden die betroffenen Zeilen zuerst aus der Triggertabelle kopiert und dann in die Tabelle „deleted“ übertragen.

Die Tabelle inserted speichert Kopien der neuen oder geänderten Zeilen nach einer INSERT- oder UPDATE-Anweisung. Während der Ausführung einer INSERT- oder UPDATE-Anweisung werden die neuen oder geänderten Zeilen in der Triggertabelle in die Tabelle „inserted“ kopiert. Die Zeilen in der Tabelle „inserted“ sind Kopien der neuen oder aktualisierten Zeilen in der Triggertabelle.

Eine Updatetransaktion ähnelt einem Löschvorgang, dem ein Einfügevorgang folgt. Während der Ausführung einer UPDATE-Anweisung tritt die folgende Ereignisabfolge auf:

  1. Die ursprüngliche Zeile wird aus der Triggertabelle in die Tabelle „deleted“ kopiert.
  2. Die Triggertabelle wird mit den neuen Werten aus der UPDATE-Anweisung aktualisiert.
  3. Die aktualisierte Zeile in der Triggertabelle wird in die Tabelle „inserted“ kopiert.

Dadurch können Sie den Inhalt der Zeile vor dem Update (in der Tabelle „deleted“) mit den neuen Zeilenwerten nach dem Update (in der Tabelle „inserted“) vergleichen.

Wenn Sie Triggerbedingungen festlegen, sollten Sie die inserted- und die deleted-Tabelle entsprechend der Aktion verwenden, die den Trigger ausgelöst hat. Es wird zwar kein Fehler ausgegeben, wenn Sie beim Testen einer INSERT-Anweisung auf die deleted-Tabelle oder beim Testen einer DELETE-Anweisung auf die inserted-Tabelle verweisen, diese Triggertesttabellen enthalten jedoch in diesen Fällen keine Zeilen.

Hinweis

Wenn Triggeraktionen von der Anzahl der Zeilen abhängen, die von einer Datenänderung betroffen sind, sollten Sie Tests verwenden (z. B. die Untersuchung von @@ROWCOUNT), die mehrzeilige Datenänderungen (eine INSERT-, DELETE- oder UPDATE-Anweisung, die auf einer SELECT-Anweisung basiert) überprüfen und die entsprechenden Vorgänge ausführen. Weitere Informationen finden Sie unter Erstellen von DML-Triggern für die Verarbeitung mehrerer Datenzeilen.

SQL Server lässt text-, ntext- oder Bildspaltenverweise in den eingefügten und gelöschten Tabellen für AFTER-Trigger nicht zu. Diese Datentypen sind jedoch nur aus Gründen der Abwärtskompatibilität eingeschlossen. Speichern Sie umfangreiche Daten bevorzugt mit den Datentypen varchar(max), nvarchar(max)und varbinary(max) . Sowohl AFTER- als auch INSTEAD OF-Trigger unterstützen varchar(max)-, nvarchar(max)- und varbinary(max) -Daten in der inserted- und deleted-Tabelle. Weitere Informationen finden Sie unter CREATE TRIGGER (Transact-SQL).

Beispiel: Verwenden der Tabelle „inserted“ in einem Trigger zum Erzwingen von Geschäftsregeln

Da sich CHECK-Einschränkungen nur auf Spalten beziehen können, für die die Einschränkung auf Spalten- oder Tabellenebene definiert wurde, müssen tabellenübergreifende Einschränkungen (in diesem Fall Geschäftsregeln) als Trigger definiert werden.

Im folgenden Beispiel wird ein DML-Trigger erstellt. Der Trigger überprüft die Bonität eines Herstellers, wenn versucht wird, eine neue Bestellung in die PurchaseOrderHeader -Tabelle einzufügen. Zum Ermitteln der Bonität des Herstellers im Zusammenhang mit der gerade eingefügten Bestellung muss auf die Vendor -Tabelle verwiesen und diese mit der inserted-Tabelle verknüpft werden. Ist die Bonität zu niedrig, wird eine Meldung angezeigt, und die Bestellung wird nicht eingefügt.

USE AdventureWorks2022;
GO
IF OBJECT_ID ('Purchasing.LowCredit','TR') IS NOT NULL
   DROP TRIGGER Purchasing.LowCredit;
GO
-- This trigger prevents a row from being inserted in the Purchasing.PurchaseOrderHeader table
-- when the credit rating of the specified vendor is set to 5 (below average).  
  
CREATE TRIGGER Purchasing.LowCredit ON Purchasing.PurchaseOrderHeader  
AFTER INSERT  
AS  
IF (ROWCOUNT_BIG() = 0)
RETURN;
IF EXISTS (SELECT 1  
           FROM inserted AS i   
           JOIN Purchasing.Vendor AS v   
           ON v.BusinessEntityID = i.VendorID  
           WHERE v.CreditRating = 5  
          )  
BEGIN  
RAISERROR ('A vendor''s credit rating is too low to accept new  
purchase orders.', 16, 1);  
ROLLBACK TRANSACTION;  
RETURN   
END;  
GO  
  
-- This statement attempts to insert a row into the PurchaseOrderHeader table  
-- for a vendor that has a below average credit rating.  
-- The AFTER INSERT trigger is fired and the INSERT transaction is rolled back.  
  
INSERT INTO Purchasing.PurchaseOrderHeader (RevisionNumber, Status, EmployeeID,  
VendorID, ShipMethodID, OrderDate, ShipDate, SubTotal, TaxAmt, Freight)  
VALUES (  
2  
,3  
,261  
,1652  
,4  
,GETDATE()  
,GETDATE()  
,44594.55  
,3567.564  
,1114.8638 );  
GO

Verwenden der Tabellen „inserted“ und „deleted“ in INSTEAD OF-Triggern

Für die inserted- und deleted-Tabellen, die an für Tabellen definierte INSTEAD OF-Trigger übergeben werden, gelten dieselben Regeln wie für die inserted- und deleted-Tabellen, die an AFTER-Trigger übergeben werden. Das Format der inserted- und deleted-Tabellen ist mit dem Format der Tabelle identisch, für die der INSTEAD OF-Trigger definiert wurde. Jede Spalte in den inserted- und deleted-Tabellen ist direkt einer Spalte in der Basistabelle zugeordnet.

Für die Frage, wann eine INSERT- oder UPDATE-Anweisung, die auf eine Tabelle mit einem INSTEAD OF-Trigger verweist, Werte für Spalten angeben muss, gelten dieselben Regeln, wie wenn in der Tabelle kein INSTEAD OF-Trigger vorhanden wäre:

  • Für berechnete Spalten oder Spalten mit einem timestamp -Datentyp können keine Werte angegeben werden.

  • Für Spalten mit einer IDENTITY-Eigenschaft können nur Werte angegeben werden, wenn IDENTITY_INSERT für diese Tabelle auf ON festgelegt ist. Wenn IDENTITY_INSERT auf ON festgelegt ist, müssen INSERT-Anweisungen einen Wert angeben.

  • INSERT-Anweisungen müssen Werte für alle NOT NULL-Spalten angeben, die keine DEFAULT-Einschränkungen aufweisen.

  • Außer in berechneten Spalten, Identitätsspalten oder timestamp -Spalten sind Werte für alle Spalten, die NULL-Werte zulassen, oder für alle NOT NULL-Spalten optional, die eine DEFAULT-Definition aufweisen.

Wenn eine INSERT-, UPDATE- oder DELETE-Anweisung auf eine Ansicht verweist, die über einen INSTEAD OF-Trigger verfügt, ruft das Datenbankmodul den Trigger auf, anstatt direkte Aktionen für eine beliebige Tabelle auszuführen. Der Trigger muss anhand der in den inserted- und deleted-Tabellen dargestellten Informationen Anweisungen erstellen, die zum Implementieren der angeforderten Aktion in den Basistabellen erforderlich sind, selbst wenn das Format der für die Sicht erstellten Informationen in den inserted- und deleted-Tabellen nicht mit dem Format der Daten in den Basistabellen identisch ist.

Das Format der inserted- und deleted-Tabellen, das an einen in einer Sicht definierten INSTEAD OF-Trigger übergeben wird, stimmt mit der Auswahlliste der SELECT-Anweisung überein, die für die Sicht definiert wurde. Beispiel:

USE AdventureWorks2022;  
GO  
CREATE VIEW dbo.EmployeeNames (BusinessEntityID, LName, FName)  
AS  
SELECT e.BusinessEntityID, p.LastName, p.FirstName  
FROM HumanResources.Employee AS e   
JOIN Person.Person AS p  
ON e.BusinessEntityID = p.BusinessEntityID;

Das Resultset für diese Sicht weist drei Spalten auf: eine int -Spalte und zwei nvarchar -Spalten. Die inserted-Tabelle und die deleted-Tabelle, die an einen für die Sicht definierten INSTEAD OF-Trigger übergeben werden, enthalten ebenfalls eine int -Spalte mit der Bezeichnung BusinessEntityID, eine nvarchar -Spalte mit der Bezeichnung LNameund eine nvarchar -Spalte mit der Bezeichnung FName.

Die Auswahlliste einer Sicht kann auch Ausdrücke aufweisen, die nicht direkt einer einzigen Basistabellenspalte zugeordnet sind. Einige Sichtausdrücke, z. B. Konstanten- oder Funktionsaufrufe, verweisen möglicherweise nicht auf Spalten und können deshalb ignoriert werden. Komplexe Ausdrücke können auf mehrere Spalten verweisen, aber die inserted- und deleted-Tabellen enthalten für jede eingefügte Zeile nur einen einzigen Wert. Dasselbe gilt für einfache Ausdrücke in einer Sicht, wenn sie auf eine berechnete Spalte mit einem komplexen Ausdruck verweisen. Ein INSTEAD OF-Trigger in der Sicht muss diese Ausdruckstypen verarbeiten.

Überlegungen zur Leistung

Da es sich bei eingefügten und gelöschten Tabellen um virtuelle, speicherresidente Tabellen handelt, sind Eigenschaften wie Statistiken oder Indizes nicht verfügbar. Obwohl einige Kardinalitätsinformationen aus diesen Tabellen verfügbar gemacht werden, sollten Sie bei Überlegungen zur Anzahl von Zeilen, die vorübergehend dort gespeichert werden sollen, vorsichtig sein. Das Einfügen einer großen Anzahl von Zeilen in diese Tabellen und das Abfragen oder Verbinden dieser Zeilen mit anderen Tabellen kann suboptimale Abfragepläne und langsame Abfrageausführungen nach sich ziehen. Entwerfen und testen Sie Ihre Anwendung sehr sorgfältig, um Ihre Anforderungen an die Abfrageleistung zu erfüllen.

Nächste Schritte

Weitere Informationen finden Sie in der Übersicht über DML-Trigger.