Linux: MySQL - Counter erhöhen und auslesen

Hallo,

wenn ich den Counter eines angeklickten Datensatzes weiterzähle, erfahre ich nicht dessen Stand:

UPDATE  termine
SET     counter = counter +1
WHERE   id = '4711'

Doch nun möchte ich bei jedem Tausender eine Aktion machen. Muss ich dafür wirklich 999 mal den Satz anschliessend vergeblich lesen?

SELECT
 counter
FROM    termine
WHERE   id = '4711'

Gruß Linux

  1. Tach,

    wenn ich den Counter eines angeklickten Datensatzes weiterzähle, erfahre ich nicht dessen Stand:

    UPDATE  termine
    SET     counter = counter +1
    WHERE   id = '4711'
    

    Doch nun möchte ich bei jedem Tausender eine Aktion machen. Muss ich dafür wirklich 999 mal den Satz anschliessend vergeblich lesen?

    wenn deine Aktion etwas Datenbankmäßiges ist, könntest du einen Trigger verwenden; ansonsten ja, es gibt meines Wissens nur für Autoincrement-Spalten eine entsprechende Funktion.

    mfg
    Woodfighter

    1. Hallo und guten Tag,

      wenn ich den Counter eines angeklickten Datensatzes weiterzähle, erfahre ich nicht dessen Stand:

      UPDATE  termine
      SET     counter = counter +1
      WHERE   id = '4711'
      

      Doch nun möchte ich bei jedem Tausender eine Aktion machen. Muss ich dafür wirklich 999 mal den Satz anschliessend vergeblich lesen?

      wenn deine Aktion etwas Datenbankmäßiges ist, könntest du einen Trigger verwenden; ansonsten ja, es gibt meines Wissens nur für Autoincrement-Spalten eine entsprechende Funktion.

      Fast richtig, aber leider nicht ganz :-)

      Einen Select-Trigger gibt es in MySQL nicht. Den kann man sich aber basteln, wenn man das Select durch eine Stored Routine durchführen lässt. In dieser kann man Bedingungen prüfen, Aktionen durchführen und ein Ergebnis zurückliefern.

      Und wenn man dann alle das normale Select auf die Tabelle unterbindet, weil man alle Select-Zugriffe geschickt über die Strored Routine ausführen lässt, kann man auch die totale Kontrolle auf die Datenbank legen, wenn man das Gleiche dann auch für Insert, Update, Delete baut.

      Der direkte Zugriff auf die Tabellen kann dann vollständig unterbunden werden. So kann niemand mehr "machen was er will".

      Sehr beliebt in Banken, Behörden, ...

      Grüße
      TS

      --
      es wachse der Freifunk
      https://harz.freifunk.net
      1. Tach,

        wenn ich den Counter eines angeklickten Datensatzes weiterzähle, erfahre ich nicht dessen Stand:

        UPDATE  termine
        SET     counter = counter +1
        WHERE   id = '4711'
        

        Doch nun möchte ich bei jedem Tausender eine Aktion machen. Muss ich dafür wirklich 999 mal den Satz anschliessend vergeblich lesen?

        wenn deine Aktion etwas Datenbankmäßiges ist, könntest du einen Trigger verwenden; ansonsten ja, es gibt meines Wissens nur für Autoincrement-Spalten eine entsprechende Funktion.

        Fast richtig, aber leider nicht ganz :-)

        Einen Select-Trigger gibt es in MySQL nicht. Den kann man sich aber basteln, wenn man das Select durch eine Stored Routine durchführen lässt. In dieser kann man Bedingungen prüfen, Aktionen durchführen und ein Ergebnis zurückliefern.

        wie kommst du auf einen SELECT-Trigger? Der OP möchte doch auf ein UPDATE reagieren.

        mfg
        Woodfighter

        1. Hallo und guten Tag,

          Einen Select-Trigger gibt es in MySQL nicht. Den kann man sich aber basteln, wenn man das Select durch eine Stored Routine durchführen lässt. In dieser kann man Bedingungen prüfen, Aktionen durchführen und ein Ergebnis zurückliefern.

          wie kommst du auf einen SELECT-Trigger? Der OP möchte doch auf ein UPDATE reagieren.

          Er möchte eine Ergebnismenge erhalten und die bekommt man mMn nur mit einem Select.

          Mit einem Update kann er zwar den Wert verändern, aber nicht gleichzeitig in eine Ergebnismenge aufnehmen. Oder reden wir jetzt aneinander vorbei? :-)

          Grüße
          TS

          --
          es wachse der Freifunk
          https://harz.freifunk.net
          1. Tach,

            Mit einem Update kann er zwar den Wert verändern, aber nicht gleichzeitig in eine Ergebnismenge aufnehmen. Oder reden wir jetzt aneinander vorbei? :-)

            deswegen schrieb ich: „wenn deine Aktion etwas Datenbankmäßiges ist, könntest du einen Trigger verwenden“; vielleicht will er ja einen anderen Datensatz updaten, dann geht das mit einem Trigger; wenn er das Ergebnis außerhalb der Datenbank braucht, wäre eine Funktion in SQL, wie du vorschlägst allerdings eine Möglichkeit, aber den Select spart man sich damit auch nicht.

            mfg
            Woodfighter

            1. Hallo und guten Abend,

              [...] aber den Select spart man sich damit auch nicht.

              Hab ich ja auch nicht behauptet.

              Ich schrieb sinngemäß:

              Wenn man sicherstellen will, dass eine bestimmte Abfrage an die Datenbank neben der gewünschten Ergebnismemge auch noch Aktionen (Updates) und Historiefunktionen (Inserts) vornehmen soll, dann kann man das mittels einer Stored Routine erreichen.

              Wenn alle rudimentäten Datenbankrequests (Select, Insert, Update, Delete, ...) über eine Stored Routine abgewickelt werden können, dann kann man den direkten Zugriff auf die Tabellen auch sperren und erhält dadurch eine "totale Kontrolle" über die Datenbank. Durch diese Schicht können dann alle (die Datenbenak betreffenden) Geschäftsregeln in der Datenbank gekapselt werden und es ist egal, mit welchem Interface man darauf zugreift (Perl, PHP, direkter Client, Emulationen, ...).

              Grüße
              TS

              --
              es wachse der Freifunk
              https://harz.freifunk.net
              1. Tach,

                Wenn man sicherstellen will, dass eine bestimmte Abfrage an die Datenbank neben der gewünschten Ergebnismemge auch noch Aktionen (Updates) und Historiefunktionen (Inserts) vornehmen soll, dann kann man das mittels einer Stored Routine erreichen.

                Wenn alle rudimentäten Datenbankrequests (Select, Insert, Update, Delete, ...) über eine Stored Routine abgewickelt werden können, dann kann man den direkten Zugriff auf die Tabellen auch sperren und erhält dadurch eine "totale Kontrolle" über die Datenbank. Durch diese Schicht können dann alle (die Datenbenak betreffenden) Geschäftsregeln in der Datenbank gekapselt werden und es ist egal, mit welchem Interface man darauf zugreift (Perl, PHP, direkter Client, Emulationen, ...).

                aber was hat das mit dem Thema zu tun und inwiefern invalidiert es meine Aussage?

                mfg
                Woodfighter

                1. Hallo und guten Abend,

                  Wenn man sicherstellen will, dass eine bestimmte Abfrage an die Datenbank neben der gewünschten Ergebnismemge auch noch Aktionen (Updates) und Historiefunktionen (Inserts) vornehmen soll, dann kann man das mittels einer Stored Routine erreichen.

                  Wenn alle rudimentäten Datenbankrequests (Select, Insert, Update, Delete, ...) über eine Stored Routine abgewickelt werden können, dann kann man den direkten Zugriff auf die Tabellen auch sperren und erhält dadurch eine "totale Kontrolle" über die Datenbank. Durch diese Schicht können dann alle (die Datenbenak betreffenden) Geschäftsregeln in der Datenbank gekapselt werden und es ist egal, mit welchem Interface man darauf zugreift (Perl, PHP, direkter Client, Emulationen, ...).

                  aber was hat das mit dem Thema zu tun und inwiefern invalidiert es meine Aussage?

                  Sind wir jetzt wieder mal im Rhetorikforum gelandet? :-(

                  Vielleicht kann der OP etwas mit meinem Hinweis anfangen. Nur, weil er die Aufgaben (Update / Select) in umgekehrter Reihenfolge benannt hat, ist es ja nicht verboten, ihm einen Lösungsweg und weitere mögliche Vorteile vorzuschlagen. Ein Trigger alleine ist jedenfalls nicht zielführend, da MySQL keine Select-Triggers kennt.

                  Grüße
                  TS

                  --
                  es wachse der Freifunk
                  https://harz.freifunk.net
                  1. Tach,

                    Sind wir jetzt wieder mal im Rhetorikforum gelandet? :-(

                    wenn du sagst, dass meine Antwort teilweise falsch oder unvollständig ist, erwarte ich, dass du auch erklärst, was du damit meinst.

                    Vielleicht kann der OP etwas mit meinem Hinweis anfangen.

                    Das kann durchaus sein, und es spricht auch nichts dagegen am ursprünglichen Thema vorbei etwas zu ergänzen, aber solange ich nicht sehe, was an meiner Antwort „nicht ganz richtig“ sein soll, werde ich nicht aufhören dagegen zu argumentieren.

                    Nur, weil er die Aufgaben (Update / Select) in umgekehrter Reihenfolge benannt hat, ist es ja nicht verboten, ihm einen Lösungsweg und weitere mögliche Vorteile vorzuschlagen.

                    Du hast ihm aber keinen Lösungsweg vorgeschlagen, wenn er den Wert aus dem Select außerhalb der Datenbank braucht, muss er den Select auf alle Fälle ausführen, wenn nicht kann er einen Update-Trigger nutzen.

                    Ein Trigger alleine ist jedenfalls nicht zielführend, da MySQL keine Select-Triggers kennt.

                    Er kann einen Update-Trigger nutzen, er braucht keinen Select-Trigger.

                    mfg
                    Woodfighter

  2. Moin!

    Doch nun möchte ich bei jedem Tausender eine Aktion machen. Muss ich dafür wirklich 999 mal den Satz anschliessend vergeblich lesen?

    Hängt von der "Aktion" ab. Du kannst aber in MySQL eine Funktionen bauen.

    Die kann den aktuellen Counter als Parameter bekommen, "dies, das und jenes" tun und am Ende einfach counter zurück liefern.

    SET     `counter` = DEINE_FUNCTION(`counter`)+1
    

    Das ist aber möglicherweise ungünstig, weil es Dein Programm "zerstückelt" und quer über das System verteilt ...

    Jörg Reinholz