corner: MySQL: Mehrstellige Zahlen werden falsch sortiert

Hallo zusammen,

ich habe folgendes Problem: ich möchte bei einer Abfrage das Ergebnis mit ORDER BY nach Preisen sortieren. Obwohl ich die entsprechende Spalte als float definiert habe, werden die darin enthaltenen mehrstelligen Zahlen nicht richtig sortiert. 7.98 wird z.B. als größer angesehen als 11.95.
Gibt es irgendeine Methode, um das Problem in den Griff zu bekommen, etwa durch eine Typumwandlung oder führende Nullen etc.?
Vielen Dank für die Antworten
Gruß

corner

  1. Hallo

    ich habe folgendes Problem: ich möchte bei einer Abfrage das Ergebnis mit ORDER BY nach Preisen sortieren. Obwohl ich die entsprechende Spalte als float definiert habe, werden die darin enthaltenen mehrstelligen Zahlen nicht richtig sortiert.

    Keine MySQL-Version, die ich bis jetzt benutzt habe, weist diesen Fehler auf.

    7.98 wird z.B. als größer angesehen als 11.95.

    Das sieht danach aus, als würden Strings sortiert.

    Gibt es irgendeine Methode, um das Problem in den Griff zu bekommen, etwa durch eine Typumwandlung.

    Ich vermute eher, dass Du durch eine Typumwandlung das Problem erst erzeugt hast. Bitte poste daher Dein SQL-Statement.

    Freundliche Grüße

    Vinzenz

    1. Ich vermute eher, dass Du durch eine Typumwandlung das Problem erst erzeugt hast. Bitte poste daher Dein SQL-Statement.

      Mein SQL-Statement:

      "SELECT IF(@a:=LOCATE('|', preis), LEFT(preis, @a - 1), preis) AS Preis FROM kategorien WHERE kat_code REGEXP '^$kat_code.*' AND preis!='' ORDER BY preis"

      1. Hallo

        Ich vermute eher, dass Du durch eine Typumwandlung das Problem erst erzeugt hast. Bitte poste daher Dein SQL-Statement.

        Mein SQL-Statement:

        "SELECT IF(@a:=LOCATE('|', preis), LEFT(preis, @a - 1), preis) AS Preis FROM kategorien WHERE kat_code REGEXP '^$kat_code.*' AND preis!='' ORDER BY preis"

        preis ist also vom Typ Zeichenkette.
        Warum wunderst Du Dich dann, dass entsprechend sortiert wird.

        Du hast also einen senkrechten Strich in Deinem Preis,
        Du suchst das was links davon ist,
        in Deiner WHERE-Klausel befindet sich Code einer Programmiersprache
        und ein Zeichenkettenvergleich, der eher ein Vergleich mit dem speziellen
        Wert NULL sein sollte, wenn die Spalte vernünftig definiert wäre.

        Warum speicherst Du Deine Daten in einem solch ungeeigneten Format?
        Wenn Du viele Daten in der Spalte hast, musst Du einen Index auf eine
        berechnete Spalte setzen, damit die Performance nicht in die Knie geht.

        Der für Preise sinnvolle Datentyp ist übrigens ein exakter Festkommawert,
        DECIMAL, siehe Handbuch - nicht float und erst recht nicht ein Zeichenkettentyp.

        Freundliche Grüße

        Vinzenz

        1. Warum speicherst Du Deine Daten in einem solch ungeeigneten Format?
          Wenn Du viele Daten in der Spalte hast, musst Du einen Index auf eine
          berechnete Spalte setzen, damit die Performance nicht in die Knie geht.

          Der für Preise sinnvolle Datentyp ist übrigens ein exakter Festkommawert,
          DECIMAL, siehe Handbuch - nicht float und erst recht nicht ein Zeichenkettentyp.

          Wie ich eben noch einmal überprüft habe, benutze ich tatsächlich eine string-Spalte. Dies tue ich deshalb, weil dort zum Teil mehrere Preise für dasselbe Produkt, entsprechend zu mehreren angebotenen Größen, eingetragen sind, die dann beim Aufbau der Webseite anhand der Trennstriche zerlegt und verarbeitet werden.
          Ich muss mir halt eine andere Abfrage ausdenken, z.B. könnte ich die zerlegten Preise in einer temporären Tabelle mit Decimal-Spalte zwischenspeichern und dann in einer weiteren Abfrage sortieren lassen.
          Vielen Dank für die Hilfe.

          corner

          1. Hallo

            Wie ich eben noch einmal überprüft habe, benutze ich tatsächlich eine string-Spalte. Dies tue ich deshalb, weil dort zum Teil mehrere Preise für dasselbe Produkt, entsprechend zu mehreren angebotenen Größen, eingetragen sind,

            das ist keine gute Idee. Du benötigst weitere Tabellen:
            eine für die angebotenen Größen und eine, die die Zuordnung von Preisen zu
            Produkt und Größe regelt. Anschließend kriegst Du mit Joins alles das, was
            Du benötigst.

            Ich wiederhole:
            Es ist nahezu immer eine ganz schlechte Idee, Daten nicht atomar abzuspeichern.

            Freundliche Grüße

            Vinzenz

            1. Ich wiederhole:
              Es ist nahezu immer eine ganz schlechte Idee, Daten nicht atomar abzuspeichern.

              Dann werde ich mal meine Datenbank umbauen. Vielen Dank für die Tipps.
              Gruß

              corner

              1. Hallo

                Dann werde ich mal meine Datenbank umbauen. Vielen Dank für die Tipps.

                eine gute Idee. Ich möchte Dir noch unsere Join-Artikel in SELFHTML aktuell
                ans Herz legen (falls Du diese nicht kennst):

                Einführung in Joins
                Fortgeschrittene Jointechniken

                Wenn Du Fragen hast, stell sie einfach hier.

                Freundliche Grüße

                Vinzenz