Query an einem Stück, möglich?

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

  • Query an einem Stück, möglich?

    Hallo ihr,

    ich habe folgende Tabelle 'Prozesse':

    | id | name | detail1 | detail2 | detail3 |

    Man darf sich die Tabelle nicht wie eine Userliste eines Forums vorstellen. Es gibt insgesamt nur 5-6 Prozesse, diese tragen sich jedoch fortlaufend hintereinander immer wieder in die Tabelle ein - eben immer, wenn sie neue Details haben.

    Die ID ist autoincrement und hat deswegen nichts mit der Identifikation der Prozesse zu tun.

    Beispiel wie das aussehen könnte:

    | 1 | Prozess 1 | ..... | ..... | ..... |
    | 2 | Prozess 3 | ..... | ..... | ..... |
    | 3 | Prozess 1 | ..... | ..... | ..... |
    | 4 | Prozess 2 | ..... | ..... | ..... |
    | 5 | Prozess 2 | ..... | ..... | ..... |


    Ich suche jetzt eine Möglichkeit, wie ich an die Details des jeweils letzten Eintrags eines Prozesses komme.
    Hintergrund ist der, das ein Prozess in einem ungünstigen Fall 2 mal hintereinander die gleichen Details besitzt. Kommt das vor, so soll das 2. Mal gar nicht erst in die Tabelle eingetragen werden, da möchte ich schon zuvor in PHP filtern. Dafür brauche ich vermutlich, wie erwähnt, aber die Details des zuletzt eingetragenen, GLEICHNAMIGEN Prozesses, um abzugleichen ob identisch.

    Klar, für jeden Prozess ne eigene Tabelle, das wäre einfacher gewesen. Aber es kann sein, dass die Prozessanzahl in Zukunft schwankt (neue kommen hinzu, alte "sterben"), da ist alles in einer Tabelle schöner.

    Am liebsten hätte ich das Auslesen der jeweils letzten Details eines Prozesses in einem Query, aber habe nur Workarounds gefunden bis jetzt.

    Mit

    PHP-Code:
    $query "SELECT name, MAX(id) FROM processes GROUP BY name"
    kann ich rausfinden, welche ID der jeweils letzte Eintrag eines Prozesses hat. Aber nun muss ich mit dieser ID wieder einen Query starten, um an die Details zu kommen... und in der Zwischenzeit kann sich in der DB schon wieder was getan haben.

    Detail1 ist übrigens ein Timestamp, aber leider nur auf eine Minute genau. In einer Minute kann Prozess X aber 10-15 neue Einträge gemacht haben, von dem her wahrscheinlich nutzlos...

    Danke und Grüße
    Zuletzt geändert von INC.; 28.04.2009, 17:34.

  • #2
    Dass das alles in einem Query möglich ist zweifle ich noch etwas an. Allerdings ein Denkanstoss bzgl. letzter ID http://de.php.net/mysql_insert_id

    Kommentar


    • #3
      Klar, für jeden Prozess ne eigene Tabelle, das wäre einfacher gewesen.
      Unfug!

      Warum speicherst du keinen Timestamp??? Die ID heißt nicht umsonst ID und nicht Timestamp!

      Benutz ORDER BY id DESC und nimm den ersten Eintrag. Fertig.

      Disclaimer: Die ID sollte generell nicht für die Sortierung verwendet werden.

      Kommentar


      • #4
        Schau dir mal Subqueries an.
        Du kannst jeden Tag wie deinen letzten leben, du musst nur jeden Tag das Gleiche tun.

        Denk' mal drüber nach!

        Kommentar


        • #5
          Danke schonmal.

          Original geschrieben von TobiaZ

          Warum speicherst du keinen Timestamp??? Die ID heißt nicht umsonst ID und nicht Timestamp!
          Wie geschrieben mach ich das doch, Mysql setzt den in Detail1 rein.
          Und dann habe ich zu einem Timestamp eventuell 20 Eintragungen, und weiter?

          Benutz ORDER BY id DESC und nimm den ersten Eintrag. Fertig.
          Dann habe ich den letzten Eintrag von irgend einem Prozess, nicht den letzten Eintrag von jeweils Prozess X, Y und Z, oder nicht?


          @Click, danke werd ich machen.

          Kommentar


          • #6
            Wie geschrieben mach ich das doch, Mysql setzt den in Detail1 rein. Und dann habe ich zu einem Timestamp eventuell 20 Eintragungen, und weiter?
            Also standardmäßig sollten die Timestamps mindestens sekundengenau sein. Zusätzlich könntest du aus der programmlogik heraus einen millisekundengenauen Timestamp erzeugen.

            Dann habe ich den letzten Eintrag von irgend einem Prozess, nicht den letzten Eintrag von jeweils Prozess X, Y und Z, oder nicht?
            Sorry, ich hatte die Kenntnis des WHERE-Arguments als Grundlage vorausgesetzt. Ich kau nicht gerne den kompletten Code vor, ein bisschen mitdenken muss drin sein.

            Zusätzliche Queries auch in form von Subqueries sind also vollkommen überflüssig, wenn man vernünftig vorgeht.

            Kommentar


            • #7
              Original geschrieben von TobiaZ
              [B]Also standardmäßig sollten die Timestamps mindestens sekundengenau sein.
              Ist wohl besser, ja. Füge jetzt vorerst UNIX_TIMESTAMP() über das Statement in der Programmlogik ein, zuvor ließ ich das MySQL automatisch mittels der Option Standard: CURRENT_TIMESTAMP machen, welche man in phpmyadmin auswählen kann. Leider gibts dort nichts zum auswählen, was nach unix timestamp aussieht, oder kann man das manuell nachtragen? Wäre schon praktischer, wenn man das aus der Programmlogik draussen hat.

              Sorry, ich hatte die Kenntnis des WHERE-Arguments als Grundlage vorausgesetzt. Ich kau nicht gerne den kompletten Code vor, ein bisschen mitdenken muss drin sein.
              Tut mir leid, habe das wohl missverstanden. Ja, die Lösung ist in der Tat eine Option, danke.

              Wollte jetzt aber noch wissen, warum du dich eigentlich gegen diese Lösung sträubst. Die ID ist doch ein eindeutiges Merkmal, während ich bei der Zeit auf Millisekunden runtermuss, wie du schon erwähntest (+ Erzeugung in der Programmlogik).

              Kommentar


              • #8
                Zwischen den Zeilen ist zu lesen, dass die Prozesse sehr viel in diese Tabelle schreiben, die Abstände zwischen den Writes daher sehr kurz sein werden. Bei zuviel Concurrency blockieren sich die Prozesse. Hast du daran gedacht? Läuft das DB-Logging asynchron (INSERT DELAYED)? Hat die DB irgendwann die Chance, die aufgestauten Writes abzuarbeiten? Ansonsten ist DB-Logging vielleicht der falsche Ansatz.

                Wenn du das alles berücksichtigst, brauchst du gar nicht per Select abfragen, ob der selbe Eintrag schon vorhanden ist. Denn die aufgestauten Writes siehst du nicht und damit wäre das Select nicht korrekt.

                Mach es mit REPLACE DELAYED und überlasse so der DB das Auffinden von Duplikaten.

                Kommentar

                Lädt...
                X