Sorierte Datenbankabfrage mit punkt und komma!?

bestella

Benutzer
Beiträge
22
Hi @all,

ich sags gleich voraus, ich bin jetzt nicht die größte Datenbank Expertin.

Ich erstelle gerade ein Worpress Theme für einen meiner Kunden. Der Kunde fragt hier über eine API Daten von einem amerikanischen Server ab, speichert diese in seiner Datenbank ab und gibt diese dann für seine Kunden (im Frontend) aus. Das ganze läuft auf PHP7 und somit eben MYSQLi


Nun funktioniert auch alles soweit es soll. Zahlenwerte werden per API wie folgt abgerufen 100,000.99
also immer drei Zeichen durch ein komma getrennt und die kommastellen folgen nach einem punkt. Der Kunde möchte, dass die Daten in "deutscher Formatieren" also genau umgekehrt (100.000,99) abgelegt werden und dem Kunden ebenfalls so ausgegeben werden. Nichts leichter als das, denn wurden die Zahlen eben vor dem Speichern umformatiert...


JETZT ZUM EIGENTLICHEN PROBLEM:
Der Kunde möchte das seine Kunden die Datensätze sortieren können und zwar eben unter anderem auch nach Zahlenwerten. mysql setzt hier ja nun leider auf das ursprungsformat zur sortierung und wertet die trenn-punkte als Kommata. Das Ergebnis ist dementsprechend nicht wie gewünscht.

Die Frage ist nun, kann man dies in MYSQL irgendwie umstellen, kennt hier jemand einen effizienten Lösungsweg, so das man die Zahlen nicht erneut umformatieren muss....????

Danke für jede Hilfe schonmal im Vorfeld
 
Werbung:
Edit: die Werte wieder umzuformatieren wäre eher keine Option, da dies bei der großen Datenmenge (mehrere 1000 Datensätze pro Aufruf) vermutlich zu sehr auf kosten der Serverleistung gehen würde.

Wenn jemand hier eine Möglichkeit kennt freue ich mich :)
 
Hallo :)

wenn die Daten per API abgerufen werden + speichern in die DB dann könnte doch die API das formatieren vor dem speichern übernehmen?! ...
 
Also Formatierung von Zahlenwerten ist nicht Aufgabe einer Datenbank. Die Datenbak, hier MySQL, hat Datentypen. Idealerweise ein Datentyp für Zahlen wie z.B. decimal(15,2). Der sortiert dann auch entsprechend nach Wert und in der Ausgabe kann dann entsprechend (landestypisch) formatiert werden.

Wenn die API das als Zeichen liefert würde ich das in jedem Fall vor dem Speichern in die DB entsprechend konvertieren.
 
Die Daten werden ja wie gesagt aus der API in das entsprechende Format formatiert (dies ist auch so Notwendig, weil beim Kunden weitere Schnittstellen auf die Daten zugreifen müssen, welche eine solche Formatierung voraussetzen).

Wie gesagt, geht es vielmehr darum die Daten in der Ausgabe, in unterschiedlichen Sortierungs-Möglichkeiten auszuliefern.
 
ok, nur nochmal das ich das auch jetzt richtig verstanden hab^^

Die Daten werden von der API schon in das richtige Format in die DB geschrieben?!?!?!
Beim Abrufen der Daten aus der DB ist das Format aber falsch bzw. für den Kunden nicht brauchbar?!?!?!


Bsp.: Daten vorher: 100,000.99 --> Daten in der DB 100.000,99 --> Daten beim Abrufen: 100,000.99

Ist das so korrekt?
 
Also nochmal der Kern meiner Antwort: Formatierung hat in der DB nichts zu suchen, eben auch weil Daten dann schwerer zu verarbeiten sind bzw. für Dinge wie Sortierung wieder erst umformatiert werden müssen. Wer also darauf bestehen möchte der muss sich im Nachgang den Ärger antun. Daten können einfach ohne Formatierung aus der DB geladen werden und vom Frontend entsprechend dargestellt werden, hat auch noch den Vorteil das weniger Datenmüll übertragen werden muss.

Deine bisherigen Posts lassen vermuten das die API das als String in der DB speichert, was dann die Probleme verursacht. Du musst jetzt die Daten in eine Zahl konvertieren und kannst damit vernünftig sortieren oder rechnen. Oder du legst in einer DB eine weitere Spalte mit dem Wert als Zahl an, überträgst nochmehr Daten hin und her und gehst das Risiko von Inkonsistenzen ein. (Von einem Webentwickler würde ich eigentlich gar nichts anderes erwarten. Soll keine Beleidigung sein aber hab ich schon zu oft gesehen...)

Nur für die Sortierung:
Code:
ORDER BY cast(replace(replace(spalte,'.',''),',','.') AS DECIMAL(15,2))
Ist jetzt MSSQL, könnte aber bei MariaDB schon direkt gehen.
 
Hi @ all,

wow, vielen Dank für eure Hilfe :*

@Dukel doch leider werden die als "VARCHAR" gespeichert und auch als solches benötigt, da wie gesagt andere Schnittstellen darauf zugreifen und dieses so voraussetzen (what ever, ist nicht von mir).

@ukulele genau, wir haben das Problem nun einfach so gelöst, dass wir die Daten quasi doppelt schreiben. Einmal im benötigten Format "VARCHAR" und einmal neu als "DECIMAL" ablegen und im Frontend, für die Ausgabe per JS umformatieren. Die Umformatierung denke ich der ineffizientere Weg oder? So würde ja bei jeder Abfrage erhöhte Serverleistung in Anspruch genommen werden.

Ich bin nun weiß Gott keine Datenbanken Koryphäe aber das sollte fürs erste passen, für weiteres habe ich dem Kunden nun empfohlen in Zukunft die Datenbank-Geschichten von jemandem machen zu lassen, der tiefergehend etwas davon versteht. Die aktuelle Lösung ist denke ich alles andere als optimal und müsste mal in ihrer Gesamtheit überarbeitet werden....

Danke an euch alle nochmal für eure großartige Hilfe! :)
 
Werbung:
Die Konvertierung "on the fly" wäre auch denkbar, die Performance ist nicht zwingend ein Problem. Aber es muss sichergestellt sein das nicht irgendwann mal etwas anderes in dem Feld steht. Sobald die Konvertierung fehl schlägt läuft das Query nicht mehr.
 
Zurück
Oben