MySql Trigger vs. Alternativen

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MySql Trigger vs. Alternativen

    Hallo,

    ich bin gerade dabei, mich ein wenig in die (für mich neuen) MySql Trigger einzulesen.
    Die Beschreibung ist ordentlich, auch findet man viele Tutorials...
    Das WIE ist also an sich nicht das Problem.

    Vielmehr bin ich gerade auf einer Seite für Mysql-Perfromance-Tipps auf die Aussage "use trigger wisely" gestoßen, ohne jedoch irgendwo nähere Angaben dazu finden zu können.
    Daraus ergeben sich für mich nun 2 Fragen, auf die ich im Netz (danke "G") leider keine ausreichenden Antworten finden konnte.
    Deswegen hoffe ich, ihr könnt mir helfen:

    a) Wie performant sind Trigger?
    Grundsätzlich ist es ja so, das ich so ziemlich jeden Trigger auch als einzelne Mysql-Anweisungen schreiben könnte.
    Also selbst ein "doppelter" Trigger, der bei einem INSERT zusätzlich ein INSERT in Tabelle 2 und ein UPDATE in Tabelle 3 machen soll, ließe sich ja auch als
    PHP-Code:
    INSERT INTO Tabelle 1...
    INSERT INTO Tabelle 2...
    UPDATE Tabelle 3 
    schreiben.
    Das sind 3 Mysql-Statements, die abgefeuert werden, während die "Trigger-Events" ja innerhalb von MySql vordefinierte Objekte feuern.


    b) Wenn ich mir nun also mein Fallbeispiel aus a) ansehe, stellt sich mir die Frage, WANN nutze ich eigentlich Trigger anstatt oben genannter Einzelanweisungen oder stored procedures?

    Mir ist bewusst, das meine Fragestellung recht allgemein sein mag, aber ich hoffe, ihr könnt mir hier ein wenig Licht ins Trigger-Dunkel bringen.

  • #2
    zu dem "wisely" gehört das vorausdenken .. du hast also deinen Trigger für Tabelle 1, der in Tabelle 2 und 3 herumfuhrwerkt - dann spinne ich mal einen weiteren Trigger dazu, der bei Insert in Tabelle 2 irgendwas in Tabelle 1 und Tabelle 3 anstellt - vielleicht wieder ein Insert - und was hast du dann gebaut ? ... eine Endlos-schleife, auf die du von außen keinen Einfluss hast - weil alles innerhalb von mysql abläuft - bei deinen Inserts von Hand hängt immer noch dein Programm / Webscript dazwischen und kann Abbruchbedingungen und Ausnahmen definieren - eben dass beim Insert in Tabelle 1 zwar die nachfolgenden beiden Inserts zwangsläufig erfolgen - aber eben NICHT so, als würdest du "natürliche" Inserts in Tabelle 2 ausführen.

    Du musst dir klarmachen, dass ein Trigger so ziemlich das dümmste Stück Programmcode, dass ich kenne - der rennt einfach stur seine Anweisungen durch - und löst halt mitunter munter weitere Trigger aus

    Im übrigen weiß ich nicht, wie gut sich Trigger mit Transaktionen vertragen. Es kann halt beim Rollback sein, dass nur die Initiale Anweisung zurückgedreht wird, aber nicht die Sekundär-Einträge durch Trigger
    Zuletzt geändert von eagle275; 11.12.2010, 19:27.
    [font=Verdana]
    Wer LESEN kann, ist klar im Vorteil!
    [/font]

    Kommentar


    • #3
      Okay, also das mit dem "dümmsten Stück Programmcode" leuchtet mir, vielen Dank @eagle

      Wenn Schritt 2 und 3 aus meinem oberen "Beispiel" lediglich Einträge/Updates in Log-Tabellen wären, bei denen ich definitiv wüsste, das ich auf Ihnen keine weiteren Trigger anwende, wären hier Trigger also durchaus ein moderates Mittel...?
      Oder spricht noch etwas dafür, lieber auf einzelne Anweisungen als auf Trigger zu setzen?

      Ich gehe davon aus, das ausgelöste Trigger-Aktionen auf annährend gleiche Weise mit den Ziel-Tabellen umgehen, also die Tabellen/Reihen genauso "locken" wie alle anderen mySql-Statements?
      Ist das korrekt?

      Kommentar


      • #4
        MySQL :: MySQL 5.0 Reference Manual :: 12.3.5.2 LOCK TABLES and Triggers

        Kommentar

        Lädt...
        X