Cast von varchar to decimal für Sortierung

[Forumsgast]

Hallo,

ich habe ein Problem mit der Sortierung von Beträgen, die vom Typ Varchar in einer MySQL Datenbank abgelegt sind. Die Werte haben ein 1000er Trennpunkt und die Nachkommastellen sind mit Komma getrennt:
BETRAG
12.544,33
534,00
12,99
1.546,88

Ich habe es mit einem Cast versucht: CAST(BETRAG AS DECIMAL(8,2)
Das funktioniert aber nicht. Ich vermute es liegt an dem Format mit 1000er Trennpunkt und Komma.

Wie müsste also das SQL aussehen, damit das Ergebnis wie folgt ist?
12,99
534,00
1.546,88
12.544,33

[Forumsgast]

Varchar ist halt der falsche Datentyp nimm decimal. Hier wird wie in der EDV üblich die amerikanische Zahlschreibweise verwendet also Dezimalpunkt und ohne Tausendertrennzeichen.

Die Darstellung in das europäische Format machst du dann mit PHP mit number_format zur Ausgabe. So kannst du immer noch mit dem Wert in PHP rechnen, was sonst wenn die DB dir das falsche Format liefert so nicht machbar wäre.

[Forumsgast]

Du musst die Punkte raus löschen, die Kommas gegen Punkte ersetzen und dann noch nach float/decimal casten.
https://dev.mysql.com/doc/refman/8.0...nction_replace

Und das möglichst nicht beim sortieren, sondern an der Stelle wo du die Daten in die Datenbank einfügst.

[Forumsgast]

test=*# select * from hans ;
     t     
-----------
 12.544,33
 534,00
 12,99
 1.546,88
(4 rows)

test=*# select *, to_number(t,'99G999D99') from hans order by to_number(t,'99G999D99');
     t     | to_number
-----------+-----------
 12,99     |     12.99
 534,00    |    534.00
 1.546,88  |   1546.88
 12.544,33 |  12544.33
(4 rows)

test=*#

[Forumsgast]

akretschmer

Du empfiehlst wirklich unterschwellig, dass er den Datentyp beibehalten soll?
Jetzt hast du dich aber in die Nesseln gesetzt... #autsch#

[Forumsgast]

akretschmer

Du empfiehlst wirklich unterschwellig, dass er den Datentyp beibehalten soll?

Hehe, nein, nicht wirklich.

[Forumsgast]

akretschmer
Du empfiehlst wirklich unterschwellig, dass er den Datentyp beibehalten soll?

Warum leckt sich der Hund die Eier?
Weil er es kann!

Aber mal ernst:
Ich finde, es ist total legitim, einfach eine hilfreiche, direkte Antwort zu geben. Wobei hilfreich auch hier mal wieder relativ ist. Regen, Traufe, usw.

Es ist das normalste der Welt, explizite Typkonvertierung zu machen, je nach Bedarf.
Es ist auch normal, es nicht ohne Not zu machen.

Und es ist oft einfach eine schäbige Gegebenheit, dass man nicht mal eben die ganze DB nach den guten Ratschlägen von php.de umbauen kann, sondern mit dem Scheiß klar kommen muss, den ein ahnungsloser Entwickler einem hinterlassen hat. (Oder sogar ein Kaufsystem über eine Schnittstelle so serviert- ein Schelm, wer böses dabei denkt)
"Schmeiß die ganze Scheiße einfach weg", das ist meistens nicht der Satz, der einem Fragesteller weiterhilft.

Wer mit mySQL arbeitet, ist workarounds gewohnt. Also was soll's?
Man kann ja neben so grundsätzlich nie angreifbaren Tipps wie: mach besser alles neu, auch noch eine adhoc Alternative nennen. Einfach "weil man es kann".

[Forumsgast]

Perry Staltic
Deinen Einwand verstehe ich.
Warten wir doch einfach mal ab was der OP dazu sagt, bis jetzt hat er sich ja noch nicht weiter geäussert und somit sind alles nur spekulative Vermutungen.

[Forumsgast]

(Sorry, musste mich noch mal korrigieren.)

#2 und #3 sind okaye Antworten.
#4 ist – meines Wissens – die übliche „am Thema vorbei“-Postgres-Antwort zu einer Frage, die sich klar auf MySQL bezieht.
#5 braucht es nicht. #6 ist lediglich eine Reaktion darauf.
#7 ist zumindest teilweise quarkiger MySQL-Hate. #8 eine Reaktion darauf.

Was versprecht ihr euch davon?

Edit: Das Feld hat offensichtlich einen ungünstigen Datentyp und wird ungünstig befüllt. Das sollte man auf Schema-Ebene und im Code fixen. Wenn das nicht möglich ist, kann man notfalls (!) Workarounds im Rahmen des genutzten DBMS finden.

[Forumsgast]

Diesen Workaround hat ja erc #3 schon angedeutet. So sollte das funktionieren:

SELECT
..
ORDER BY
  CAST(REPLACE(REPLACE(strnum,".",""),",",".") AS DECIMAL(8,2))