Marco Heller: Trigger für MS SQL Server

Hallo!

Ich habe folgende Ausgangssituation. In der Datenbank befinden sich zwei Relationen:
TabelleA mit den Spalten IdA und ContentA
in der TabelleB befinden sich die Spalten IdA und ContentB.
Mit einem Trigger (oder auch Check Clause, ist mir eigentlich einerlei)  möchte ich folgendes erreichen. Wenn in TabelleA ein Datentupel eingefügt oder geändert wird, soll geprüft werden ob Daten mit der gleichen IdA in der jeweils anderen Tabelle existiert. Der Datensatz aus der anderen Tabelle soll dann gelöscht werden.
Als das Query ist kein Problem (im Trigger von TabelleA: DELETE FROM TabelleB WHERE IdA = ), nur wie übergebe ich die Id?

Gruß
Marco

  1. Hallo,

    weiß nicht ob es so geht, aber auf die Schnelle (nur für Insert):

    CREATE TRIGGER trig_insTabA

    ON TabelleA

    FOR INSERT

    AS

    DECLARE @IdA integer

    SELECT @IdA = (SELECT IdA FROM Inserted)

    DELETE FROM TabelleB WHERE IdA = @IdA

    Du hast bei Triggern Zugriff auf die virtuelle Tabelle Inserted.

    Gruß
    LeKuchen

  2. Hallo,

    innerhalb von Triggern in MS SQL Server gibt es die beiden Pseudotabellen "inserted" und "deleted", bei einem Update beinhaltet "deleted" dann die alte Version und "inserted" die neue Version der Daten. Auf diese kannst du ganz einfach mit SELECT zugreifen:

    DELETE TabelleB WHERE IdA IN (SELECT IdA from inserted)

    Du musst allerdings noch beachten, dass ein Trigger nicht für jeden eingefügten / geänderten / gelöschten Datensatz bei einer Mengenoperation ausgeführt wird sondern 1x pro Operation. (ein INSERT ... SELECT ... FROM ... fügt vielleicht 30000 Datensätze ein, der Trigger wird aber nur einmal gefeuert)

    Mit einem Trigger (oder auch Check Clause, ist mir eigentlich einerlei)

    Du kennst also nicht den Unterschied und willst ihn auch gar nicht kennen? Fühlst du dich damit für Entwicklungsaufgaben nicht selbst etwas disqualifiziert?

    Ciao, Frank

    1. Guten Tag!

      Vielen Dank für Ihren Lösungshinweis.

      Du kennst also nicht den Unterschied und willst ihn auch gar nicht kennen? Fühlst du dich damit für Entwicklungsaufgaben nicht selbst etwas disqualifiziert?

      Die Änderungen am Datensatz erfolgen bei mir OneByOne über eine StoredProcedure. Ich nahm daher an, dass sowohl eine CheckClause als auch ein Trigger eine Möglichkeit zur Lösung meines Problems bietet. Was von beidem besser ist, in Bezug auf Performace oder Konsistenzerhaltung, hoffte ich in einer Diskussion an dieser Stelle zu erfahren.
      Mir daraufhin Ingnoranz zu unterstellen kann ich leider nicht nachvollziehen.

      So long
      Marco

      1. Hallo,

        Die Änderungen am Datensatz erfolgen bei mir OneByOne über eine StoredProcedure.

        Wenn Du schon eine Stored Procedure hast, warum machst Du die notwendigen Operationen nicht gleich in dieser?

        Grüße
          Klaus

        1. Servus!

          Wenn Du schon eine Stored Procedure hast, warum machst Du die notwendigen Operationen nicht gleich in dieser?

          Tatsächlich tut sie das sogar. Ich war dennoch an einer Lösung mit Trigger interessiert.

          Liebe Grüße
          Marco

      2. Hi,

        wenn du schreibst, es sei dir "einerlei", kennst du faktisch den Unterschied nicht, sonst wüsstest du, dass sich mit Check-Klauseln kein DML (Updates, Inserts, Deletes) durchführen lässt. Eine Check-Klausel auf Spalten oder Tabellen-Level muss ein logisch (true oder false) auswertbarer Ausdruck sein.

        CHECK Constraints sind für dein Vorhaben das definitiv falsche Mittel, so dass sich eine Diskussion um bessere Performance oder Konsistenzerhaltung erübrigt. Die Verwendung von CHECK Constraints kannst innerhalb von 30 sekunden in deinem Manual (SQL Books Online) nachschlagen. Und so einerlei kann es dir dann ja auch nicht sein, wenn du nach der besseren Performance

        Eine Betrachtung zwischen den Alternativen Trigger und Integration in die ursprüngliche Stored Procedure könnte man tätigen.

        Den Hinweis das Trigger nur pro Menge betroffener Datensätze und nicht einzeln für jeden Datensatz gefeuert werden, kam deshalb weil es für gewöhnlich der 2. Anfängerfehler ist, diesen Aspekt von Triggern ausser Acht zu lassen.

        Cheers, Frank

        1. Eine Betrachtung zwischen den Alternativen Trigger und Integration in die ursprüngliche Stored Procedure könnte man tätigen.

          Richtig, letzteres ist fast immer vorzuziehen. Trigger sind wenig pflegeleicht (was die Weiterentwicklungsfähigkeit und dem Betrieb des Gesamtsystems wenig guttut, man denke bspw. an Herden von Triggern, die den SPs "beistehen") und darum nur zu verwenden, wenn alternativlos (typisches Beispiel: Jede DML-Operation an der Tabelle "MA-Gehaelter" feuert eine E-Mail an den Personalchef).

          Übrigens gibt der MS SQL Server dem Programmierer ein recht grosses Instrumentarium, das geradezu einlädt zum Mismanagement. Besonders wenn man noch die Schichten ADO (bzw. DAO, ActiveF???) nutzt, dann kanns richtig den Bach runtergehen.