Ankündigung

Einklappen
Keine Ankündigung bisher.

SQL für Auswertung

Einklappen

Neue Werbung 2019

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

  • SQL für Auswertung

    Hallo zusammen,

    ich habe eine MySQL Datenbank, in der die Ergebnisse eins Triathlons stehen:

    In einer Tabelle habe ich ich die Stammdaten der Teilnehmer, in einer anderen die Messungen.

    Code:
    select teilnehmer.startnummer, teilnehmer.name, teilnehmer.vorname, teilnehmer.geschlecht, teilnehmer.jahrgang, teilnehmer.verein, 
    (select messungen.zeit from messungen where startnummer = teilnehmer.startnummer and messungen.messpunkt = 3 order by messungen.zeit LIMIT 0 , 1 ) as schwimmen,
    (select messungen.zeit from messungen where startnummer = teilnehmer.startnummer and messungen.messpunkt = 4 order by messungen.zeit LIMIT 0 , 1 ) as laufen,
    (select messungen.zeit from messungen where startnummer = teilnehmer.startnummer and messungen.messpunkt = 5 order by messungen.zeit LIMIT 0 , 1 ) as ziel
    from teilnehmer 
    where teilnehmer.wettkampf = 91
    order by ziel, laufen, schwimmen
    Nun kann es sein, das nicht für jeden Teilnehmer bei jedem Messpunkt (schwimmen, laufen, ziel) eine Zeit vorliegt. Daher erhalte ich dann in der Abfrage NULL.
    Ich möchte gerne, dass wie angegeben sortiert wird, aber das NULL am ende steht. Die Ausgabe der Zeit ist eine Feld mit dem Datentyp time.

    hat Jemand eine Idee?

    Vielen Dank,


  • #2
    ORDER BY ... NULLS {FIRST | LAST}

    Zumindest in PostgreSQL.
    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

    Kommentar


    • #3
      Geht leider bei MYSQL nicht:
      Code:
      19:35:21 select teilnehmer.startnummer, teilnehmer.name, teilnehmer.vorname, teilnehmer.geschlecht, teilnehmer.jahrgang, teilnehmer.verein,
      (select messungen.zeit from messungen where startnummer = teilnehmer.startnummer and messungen.messpunkt = 3 order by messungen.zeit LIMIT 0 , 1 ) as schwimmen,
      (select messungen.zeit from messungen where startnummer = teilnehmer.startnummer and messungen.messpunkt = 4 order by messungen.zeit LIMIT 0 , 1 ) as laufen,
      (select messungen.zeit from messungen where startnummer = teilnehmer.startnummer and messungen.messpunkt = 5 order by messungen.zeit LIMIT 0 , 1 ) as ziel
      from teilnehmer where teilnehmer.wettkampf = 91 order by ziel NULLS Last
      Error Code: 1064. You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'NULLS Last' at line 7 0.078 sec

      Kommentar


      • #4
        Tue uns allen bitte den Gefallen deinen Posts zu formatieren, so ist es fast unmöglich das zu erfassen.

        Ps. Und die Posts von akretschmer kann man fast immer ignorieren, da er in postgres schon träumt.

        Kommentar


        • #5
          Du kannst die Sortierspalte bzw. einen Ausdruck dafür selber zusammenstellen:
          ~Nimm den Messwert und wenn der NULL sein sollte, nimm statt dessen eine hinreichend große Zahl als Ersatz.
          Das geht mit CASE WHEN ..
          Nach diesem Ausdruck sortierst Du, als Ausgabe verwendest Du die Originalwerte.

          Das Sortieren auf diesem Ausdruck wird nicht so schnell sein, wie auf dem Originalwert, aber soviel 1000 Teilnehmer werden es nicht sein, dass es stört.

          Kommentar


          • #6
            Ich habe gerade noch etwas anderes gefunden, wo ich aber nicht erklären kann warum das funktioniert:
            Code:
            order by isnull(ziel), ziel, isnull(laufen), laufen, isnull(schwimmen), schwimmen
            Es kommt aber das richtige bei raus.

            Kommentar


            • #7
              Ah, wusste nicht, dass mysql das hat. Hast Du Dir mal angeschaut, was isnull() ausgibt? Damit erklärt sich dann der Effekt eigentlich von selbst:
              Es macht etwas ähnliches wie case when, allerdings nicht so flexibel mit beliebigen Expression Ergebnissen.
              Es wertet nur aus- naheliegend-, ob der Ausdruck NULL ist oder einen echten Wert enthält. Für Dich spannend ist hier, was er ausgibt, denn das verwendest Du ja bei der Sortierung.
              Bei NULL gibt er 1 aus, bei nicht NULL gibt er 0 aus, danach wird laut Deiner Order Anweisung sortiert und zwar bevor nach dem eigentlichen Messwert sortiert wird. 0 ist kleiner 1, es werden erst alle Sätze mit vorhandenen Messwerten genommen, dann die ohne Messwert, dann wird nach dem 1. Messwert selbst sortiert, dann kommen die fehlenden Messwerte.

              Kommentar


              • #8
                Ist noch die Frage, ob ein berechnetes Sortierkriterium langsamer als zwei Kriterien sein sollen. Vermute mal das Gegenteil. Für das obige Problem kann auch IFNULL benutzt werden.
                Ist auch für meine Begriffe etwas verständlicher.
                Code:
                 order by ifnull(ziel,100000),..

                Kommentar


                • #9
                  Siehe auch: https://php-de.github.io/jumpto/sql-...ort/#bedingung
                  The string "()()" is not palindrom but the String "())(" is.

                  Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                  PHP.de Wissenssammlung | Kein Support per PN

                  Kommentar


                  • #10
                    Zitat von jspit Beitrag anzeigen
                    Ist noch die Frage, ob ein berechnetes Sortierkriterium langsamer als zwei Kriterien sein sollen. Vermute mal das Gegenteil.
                    Doch, wird langsamer sein, da kein Index mehr verwendet werden kann (MySQL kennt keine funktionalen Indexe)
                    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                    Kommentar


                    • #11
                      Meine Frage war unsauber formuliert bzw. trifft nicht ganz das Problem hier. Denn in der Lösung #6 ist ja eines von den zwei Kriterien genaugenommen auch berechnet.

                      Kommentar


                      • #12
                        Zitat von akretschmer Beitrag anzeigen

                        Doch, wird langsamer sein, da kein Index mehr verwendet werden kann (MySQL kennt keine funktionalen Indexe)
                        Zitat von jspit
                        Meine Frage war unsauber formuliert bzw. trifft nicht ganz das Problem hier. Denn in der Lösung #6 ist ja eines von den zwei Kriterien genaugenommen auch berechnet.
                        Hier muss man beachten, dass es nicht(!) um eine Where Clause geht, wo ein Index noch viel einfacher verwendet werden kann bzw. sein Standardeinsatzgebiet hat. Die Limitierung, dass Funktionen den Indexzugriff per se verhindern, gilt zwar auch bei Order By, aber eben dort wird sowieso noch viel seltener ein Index verwendet. Diese -ich nenn es mal Sonderfälle - wo die Indexnutzung noch möglich ist, lliegen z.B. vor, wenn die Orderspalte ein indiziertes (Primär)schlüsselfeld ist und gar keine Where Bedingung vorhanden ist oder die Where Bedingung und die Order By jeweils auf Teile eines mehrspaltigen Schlüssels zugreifen uvma.

                        Kurz, es ist sowieso sehr unwahrscheinlich, das oben im SQL Order By überhaupt ein Index verwendet wird. Der Einsatz der Funktion im Order By führt folglich also nicht zu einer Verlangsamung (mangels Indexzugriffsmöglichkeit). (Bis auf die Tatsache, das die Funktionsberechnung natürlich auch Zeit kostet,wird hier nicht betrachtet)

                        Dieses Verhalten unterscheidet sich m.E. prinzipbedingt auch nicht weitreichend von anderen Systemen, da die Ergebnismenge eines beliebigen Queries auch strukturell beliebig "weit entfernt" ist von der indizierten Menge (Kern-Tabellle). Es handelt sich je nachdem um eine Datenmenge, die im Buffer oder wenn zu groß quasi als temporäre Tabelle gehalten wird.
                        Erst im letzten Fall wird es auch wirklich langsam, da eben z.B. sorts oder groups dann die Ergebnismenge auf der "Platte" abgrasen oder umbauen müssen (ohne nutzbare Indizes). Passt die (kleine) Ergebnismenge in den Buffer, ist das Sortieren usw. nur etwas "Kopfrechnen" für die DB und m.E. zu vernachlässigen.

                        Im vorliegenden Fall ist von der Teilnehmermenge eines Wettkampfes die Rede, also eine kleine Menge, keine Probleme zu erwarten.

                        Kommentar


                        • #13
                          Zitat von Perry Staltic Beitrag anzeigen

                          Hier muss man beachten, dass es nicht(!) um eine Where Clause geht, wo ein Index noch viel einfacher verwendet werden kann bzw. sein Standardeinsatzgebiet hat. Die Limitierung, dass Funktionen den Indexzugriff per se verhindern, gilt zwar auch bei Order By, aber eben dort wird sowieso noch viel seltener ein Index verwendet.
                          Das mag alles stimmen. Für MySQL. Insbesondere, weil MySQL je Tabelle in einer Abfrage eh nur einen Index nutzen kann. Indexe können aber nun mal auch eine Menge geordnet liefern, wenn es im Sinne der Anfrage nützlich ist. Irgendwann wird MySQL das Ganze sicher auch mal alles viel besser können als derzeit noch, es ist also nicht falsch, auf solche Dinge hinzuweisen, denke ich.
                          PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                          Kommentar


                          • #14
                            Natürlich, der zitierte Teil bezieht sich auf MySQL. Darum ging es ja hier und darum ging es auch in dem Teil, den ich von Dir zitiert habe.
                            Ich habe das deswegen hervorgehoben, weil ich kurz gesagt, Deine Bemerkung zu funktionalen Indices in Order By in diesem Thread für irreführend halte.
                            Es war sicher alles andere als falsch, auf die Order By Problematic hinzuweisen.

                            Kommentar

                            Lädt...
                            X