Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] trigger - wert von einer Tabelle in eine andere eintragen.

Einklappen

Neue Werbung 2019

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

  • [Erledigt] trigger - wert von einer Tabelle in eine andere eintragen.

    Einen schönen guten Tag!
    ich bin Anfänger und habe ein Frage.

    Ich habe eine Tabelle1 mit den Spalten: (id_tabelle1 / id_tabelle2/ wert1 /wert3) und eine Tabelle 2 mit den Spalten: ( id_tabelle2 / wert2 / wert4)

    id_xx sind Priärschlüsseln und Auto_increm
    id_tabelle2 sind mit Join verküpft.

    Ich möchte gerne nach dem der Wert1 in Tabelle 1 eingetragen wurde, automatisch in tabelle2 wo der wert id_tabelle2 (von Tabelle1) = id_tabelle2 (in Tabelel2) den Wert 2 mit dem wert 1 aus Tabelle 1 überschreiben.

    Die Prozedur muss so erfolgen.

    Ich habe mich mit dem Trigger auseinander gesetzt. Un dich mache immer etwas falsch. Ich habe die Bedingung das es dort in T2 eingetragen werden soll wo id_tabelle2 = id_tabelle2 und es ganz einfach gemacht.
    Bei neuem Datensatz in T1 >> neuer Datensatz in T2 selbst das geht nicht. Es ist mir wirklich peinlich.

    1) über phpmyadmin > in Tabelle 1 > Trigger wählen > neuen Trigger erstellen.

    Triggername: T1_in_T2
    Tabelle: tabelle1
    Zeit: After
    Ereignis: Insert

    VARIANTE1:
    Beschreibung: insert into tabelle2 (id_tabelle2, wert2) values ('new.id', 'wert1')
    _________

    Befehl:
    CREATE TRIGGER `tabele1intabelle2` AFTER INSERT ON `tabelle1`
    FOR EACH ROW insert into tabelle2 (id_tabelle2, wert2) values ('new.id', 'wert1')

    Variante2:
    Beschreibung: insert into tabelle2 (wert2) values ('wert1')

    MySQL meldet: #1442 - Can't update table 'tabelle2' in stored function/trigger because it is already used by statement which invoked this stored function/trigger.

    Ich habe auch verschieden andere Möglichkeiten probiert leider ohne Erfolg.
    Auch ordentlich mit Begin und END usw.

    Ich wäre wirklich dankbar wenn Ihr ein Lösung hättet (wäre genial wenn ihr auch gleich die Abfrage nach der Id_tabelle2 einbauen könntet)

    Herzlichen Dank

    Liebe Grüße
    Georg


  • #2
    Hi,

    Trigger sind zwar praktisch, aber betrunken mit dem Auto heimfahren ist es auch. Also keine gute Idee. Hast du denn keine Funktion/Methode, die das Speichern des Werts in Tabelle1 übernimmt und die dann eben auch eine Aktion für Tabelle2 anstossen kann?

    PHP-Code:
    <?php
    public function saveTable1(Data $data) {
      
    $this->db->insert('table1'$data->toArray());
      
    // und hier jetzt auch in table2 eintragen
    }
    ?>
    Das wäre verständlicher und einfacher. Habe das mit den Triggern so auch mal verwendet, als Historisierung sozusagen. Funktioniert zugegeben immer noch und ohne Probleme; anfassen möcht ich das Ding trotzdem nicht mehr.
    "Mein Name ist Lohse, ich kaufe hier ein."

    Kommentar


    • #3
      Zitat von Chriz Beitrag anzeigen
      Hi,

      Trigger sind zwar praktisch, aber betrunken mit dem Auto heimfahren ist es auch. Also keine gute Idee. Hast du denn keine Funktion/Methode, die das Speichern des Werts in Tabelle1 übernimmt und die dann eben auch eine Aktion für Tabelle2 anstossen kann?

      Ich erspare mir einen Vergleich wie Deiner oben, denn deine Idee ist auch keine gute. Datenbanken haben Dinge wie RI, Trigger, Check-Constraints u.a. eben um sie zu nutzen.

      Für den Fragesteller:

      Code:
      test=# create table t1 (id int, val int);
      CREATE TABLE
      test=*# create table t2 (id int, val int);
      CREATE TABLE
      test=*# create or replace function t1_2_t2() returns trigger as $$begin insert into t2 values(new.id, new.val); return new; end;$$language plpgsql;
      CREATE FUNCTION
      test=*# create trigger trg1 after insert on t1 for each row execute procedure t1_2_t2();
      CREATE TRIGGER
      test=*# insert into t1 values (1,10);
      INSERT 0 1
      test=*# select * from t2;
       id | val
      ----+-----
        1 |  10
      (1 row)
      Das ist jetzt allerdings, tätää, PostgreSQL. Möglicherweise geht es aber ähnlich in MySQL. Du müßtest das natürlich noch anpassen auf den Fall, daß der Datensatz mit der ID schon da ist. MySQL hat ja für sowas sogar MERGE, soweit ich weiß.

      Davon abgesehen: das ist redundant. Aber via TRIGGER z.B. Ergebnisse 'vorzuberechnen' muß nicht immer schlecht sein. PostgreSQL 9.3, was in 1-2 Wochen released wird, kennt für sowas dann auch 'materialized views', mal so als Blick übern Tellerrand.
      PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

      Kommentar


      • #4
        Trigger einen Wert in Tabelle tragen

        Hallo,
        danke für die schnelle Antwort.

        Die Tabelle1 muss als erstes mit den Wert1 befüllt werden. Und wenn der Wert in T1 eingetragen ist dann darf der wert1 in Tabelle2 in die Spalte Wert2 übertragen werden, wo der wert id_tabelle2 (von Tabelle1) = id_tabelle2 (in Tabelel2)

        Ich dachte dafür ist der Trigger da. Um auch Loggs durchzuführen usw.
        Frage was ist an einen Trigger so unverlässlich?

        Es müsste nur eine oder zwei Zeilen sein. Ich habe keine Ahnung warum die Trigger nicht funktionieren. Habe viele Varianten nach Anleitung probiert.
        Entweder habe ich ein grundlegenden Fehler.

        Kann mir vielleicht Doch einer von Euch Spezialisten die ganz konkreten Zeilen für mein Anliegen in MySql aufschreiben.
        Leiber akretschmer Dein Beispiel konnte ich nicht zum laufen bringen.

        Danke für die Hilfe
        Liebe Grüße
        Georg

        Kommentar


        • #5
          Hallo,
          ich habe die Lösung und den Fehler gefunden.

          Ich habe einen zweiten Trigger in einer anderen Tabelle nicht gelöscht gehabt und damit eine Endlosschleife erzeugt.

          Lösung:
          Code für sql:
          CREATE TRIGGER `t1zut2` AFTER INSERT ON `tabelle1`
          FOR EACH ROW BEGIN
          UPDATE tabelle2 SET wert2 = NEW.wert1 WHERE id_tabelle2 = NEW.id_tabelle2;
          END

          oder in phpmyadmin > tabelle1 > trigger
          trigger hinzufügen >

          Triggername: T1_in_T2
          Tabelle: tabelle1
          Zeit: After
          Ereignis: Insert

          Beschreibung:
          BEGIN
          UPDATE tabelle2 SET wert2 = NEW.wert1 WHERE id_tabelle2 = NEW.id_tabelle2;
          END

          Kommentar


          • #6
            Zitat von akretschmer Beitrag anzeigen
            Ich erspare mir einen Vergleich wie Deiner oben, denn deine Idee ist auch keine gute. Datenbanken haben Dinge wie RI, Trigger, Check-Constraints u.a. eben um sie zu nutzen.
            Phrasensatz ohne Inhalt, die liebe ich ja. Deine Aussage: Mein Vorschlag schlecht, Datenbankfeatures nutzen! Das ist echt hilfreich.
            "Mein Name ist Lohse, ich kaufe hier ein."

            Kommentar


            • #7
              Zu dem Phrasensatz hast Du aber eindeutig die Vorlage gegeben, Chriz.

              Ich bin zwar auch nicht der Freund davon, zu viel Logik in die DB zu stopfen, aber bis zu einem gewissen Grad macht es schon Sinn, sowas zu tun. Trigger & co sind jedenfalls definitiv nicht pauschal Teufelszeug. Hier haste ne Hand voll Argumente. Es gibt aber auch jede Menge Leute, die in die andere Richtung argumentieren werden.

              Gruß Jens

              Kommentar


              • #8
                Zitat von Jens Clasen Beitrag anzeigen
                Ich bin zwar auch nicht der Freund davon, zu viel Logik in die DB zu stopfen, aber bis zu einem gewissen Grad macht es schon Sinn, sowas zu tun.
                Die Argumentation gegen Dinge wie RI, TRIGGER etc. kommt immer wieder aus der MySQL-Ecke, und ich denke, das hat handfeste Ursachen. Die Doku von MySQL 3.x z.B. nannte Features wie RI unsinnig und wer es bräuchte möge das in der Applikation machen. Kein Witz.

                Wenn man, was mit Oracle und PG z.B. recht gut möglich ist, seine Geschäftslogig massiv in die Datenbank schiebt, wird man merken, welche Vorteile das bringt. Wir haben bei uns Kunden, die das sehr intensiv machen.
                PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                Kommentar


                • #9
                  und damit prompt in die Falle getappt ...Geschäftslogik ist eben DAS - PROGRAMM = Software und gehört daher in die Anwendung

                  Oder willst du uns jetzt erzählen, es sei ne tolle Idee in einer Datenbanktabelle die möglichen SQL-Abfragen zu haltenen, die dann mittels stored procedure sozusagen nur "indirekt" aufgerufen werden können?
                  Zitat von nikosch
                  So glatt kann doch wirklich keiner sein.

                  Kommentar


                  • #10
                    Zitat von beliar284 Beitrag anzeigen
                    und damit prompt in die Falle getappt ...Geschäftslogik ist eben DAS - PROGRAMM = Software und gehört daher in die Anwendung

                    Oder willst du uns jetzt erzählen, es sei ne tolle Idee in einer Datenbanktabelle die möglichen SQL-Abfragen zu haltenen, die dann mittels stored procedure sozusagen nur "indirekt" aufgerufen werden können?
                    Du hast hier schön erklärt, daß Dir nicht bekannt ist, was mit prozeduralen Sprachen wie pl/pgsql machbar ist. Danke.

                    Andreas
                    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                    Kommentar


                    • #11
                      Es ist grundsätzlich eine tolle Idee, Geschäftslogik nur einmal, d.h. "zentral" zu entwickeln. Auch eine Stored Procedure kann dafür der richtige Platz sein. Die Datenbank ist in Client-Server-Umgebungen Teil des Programms.

                      Das das nicht noch mehr gemacht wird, hat mehr zur Ursache, dass die verwendeten Programmiersprachen der DBMS nach wie vor nur begrenzt was taugen. (Und ja: inklusive Postgres, Oracle & co). Es gibt einfach noch zu viel Business Logik, die sich nur mit Hängen und Würgen unterbringen lässt. Die Implementierung im Datenbank-Client ist daher einfach in der Entwicklung kostengünstiger, zumindest wenn wir nicht von tausend unterschiedlichen Client-Software-Systemen reden, die auf die selbe Datenbank zugreifen.

                      MySQL ist da allerdings wirklich ein Extremfall. Da war die Unterstützung derartiger Techniken über Jahre so schlecht, dass vielfach aus der Not eine Tugend gemacht wurde und der Notzustand zur einzig wahren Weltreligion erhoben wurde.

                      Bei solchen Sachen muss man IMHO einfach zwischen Speicher/Storage-Logik und echter Geschäftslogik unterscheiden. Der Data-Tier-Part gehört dabei durchaus in die DB, wenn man über ein geeignetes DBMS verfügt. Für echte Geschäftslogik gilt das nicht immer. Wie üblich, liegt die Wahrheit hier in der Mitte.

                      Aber wie auch immer: Über diese Geschichte sind schon Religionskriege geführt worden. Ich glaub kaum, dass es Sinn macht, wenn wir für einen neuen davon diesen Thread kapern.

                      Gruß Jens

                      Kommentar


                      • #12
                        Zitat von akretschmer Beitrag anzeigen
                        Die Argumentation gegen Dinge wie RI, TRIGGER etc. kommt immer wieder aus der MySQL-Ecke, und ich denke, das hat handfeste Ursachen. Die Doku von MySQL 3.x z.B. nannte Features wie RI unsinnig und wer es bräuchte möge das in der Applikation machen. Kein Witz.
                        #Neuland. Erst mit Mysql 5 wurde Logik für den Otto Normalentwickler in der Datenbank möglich. Leider ist der Funktionsumfang recht eingeschränkt. Für ein paar Performance Tweaks reicht es, aber eine Thick Database stößt da ganz schnell an die Grenzen.

                        Zitat von beliar284
                        und damit prompt in die Falle getappt ...Geschäftslogik ist eben DAS - PROGRAMM = Software und gehört daher in die Anwendung
                        Vielleicht solltest du dich erstmal schlau machen was ein Programm, eine Anwendung und Software ist... evtl. auch gleich mal nach Schichtenarchitektur googlen.

                        Kommentar


                        • #13
                          Zitat von Jens Clasen Beitrag anzeigen
                          Es ist grundsätzlich eine tolle Idee, Geschäftslogik nur einmal, d.h. "zentral" zu entwickeln. Auch eine Stored Procedure kann dafür der richtige Platz sein. Die Datenbank ist in Client-Server-Umgebungen Teil des Programms.
                          ACK.

                          Das das nicht noch mehr gemacht wird, hat mehr zur Ursache, dass die verwendeten Programmiersprachen der DBMS nach wie vor nur begrenzt was taugen. (Und ja: inklusive Postgres, Oracle & co).
                          An welche Sprachen denkst Du da? Dir ist bekannt, daß Du innerhalb von PG u.a. auch mit PERL, PHP, Java und anderen Sprachen programmieren kannst?
                          PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                          Kommentar


                          • #14
                            Das kannst Du nicht nur unter Postgres. Grundsätzlich bekannt also ja, auch wenn ich damit noch nicht so viel gearbeitet habe.

                            Das ist aber nicht so wirklich der Standard-Anwendungsfall. Der Standard-Anwendungsfall für Postgres ist ja eher PL/pgSQL (und vielleicht - mit ein paar Abstrichen - einer der anderen großen drei) Analoge DSL haben ja auch die meisten anderen DBMS im Angebot - in rudimentärer Form sogar MySQL. Hauptsächlich hab ich an diese Sprachen gedacht, als ich das ganze als "taugt begrenzt was" für den Anwendungsfall Business-Logik bezeichnet habe.

                            Allerdings haben auch die "richtigen" Programmiersprachen ihre Schwächen, wenn sie z.B. im Kontext "trigger" oder Stored Procedure eingesetzt werden sollen. Hier dreht sich die Spezialisierungsproblematik von oben genau um. Das was PL/pgSQL gut kann (Cursor verarbeiten, Interaktion mit Queries, können diese Sprachen schlecht.)

                            Eine OOPisierte Sprache mit wirklichen Talenten in der Massendaten-Verarbeitung könnte das Leben da vielleicht erleichtern. Wo wohnt noch gleich die eierlegende Wollmilchsau?

                            Die PHP-Geschichte kannte ich allerdings noch nicht. Ich hab da eben aber mal hingeschaut und gleich im letzten Satz zur Doku das hier gefunden:

                            PL/php functions cannot call each other directly because their names are mangled.

                            SPI calls have the whole results allocated in memory, so processing huge results may be problematic. Also it's not possible to use cursors with SPI.
                            Damit wäre das im PHP-Umfeld mehr oder minder unbrauchbar.

                            Der Vorteil der Einsetzbarkeit "anderer" Programmiersprachen besteht in der gemeinsamen Nutzung von Code zwischen Datenbank-getriggerten Events und Client-getriggerten Events. Wenn ein INSERT oder UPDATE via Trigger z.B. eine Event-Message via Socket an einen Client schicken kann und , dann wird es spannend. Wenn das weg fällt, kann man u.Umst. auch ganz gut darauf verzichten.

                            Problem dabei ist allerdings, dass der Aufwand für eine Implementierung des selben in der Datenbank häufig um einiges höher oder von den Entwickler-Kosten teurer ist, als wenn ich das auf "hörerer" Ebene in einem Storage-Layer direkt nach INSERTS oder UPDATES mache.

                            Aber wie gesagt: Das ist ne Einzelfall-Entscheidung. Pauschalieren will ich das in keine Richtung.

                            Gruß Jens

                            Kommentar


                            • #15
                              Zitat von Jens Clasen Beitrag anzeigen
                              Zu dem Phrasensatz hast Du aber eindeutig die Vorlage gegeben, Chriz.
                              Och menno
                              "Mein Name ist Lohse, ich kaufe hier ein."

                              Kommentar

                              Lädt...
                              X