Tach!

Imho sind Integer aus der Datenbank einfacher zu interpretieren, zumal du im Idealfall das Rechnen / die Verarbeitung nur mit Integern vornimmst. Dann musst du in deinem Quellcode nicht drauf achten und kannst gezielt immer nur dann, wenn der User damit in Berührung kommt (I/O), in float umwandeln (geteilt durch 100) und wieder zurück.

Na nee, das floaten wollen wir ja grad vermeiden. Der Rundungsfehler soll auch nicht kurz vorm Ziel auftreten. Lieber eine stringverarbeitende Funktion zum Formatieren des Integers schreiben.

substr_replace(123456789, '.', -2, 0)

Damit bekommt man einen Dezimalpunkt in die Zahl, ohne dass gerechnet und gerundet wird. Wenn man nun noch Tausender-Trenner braucht, wird es etwas aufwendiger. Ich wollte da noch number_format() draufsetzen, aber das konvertiert vermutlich nach Float, weil es sowas als Parameter haben möchte. Eigentlich wollte ich das mal testen, aber ich fand keine Zahl bis 7-stellig, bei der beim Teilen durch 100 ein Rundungsfehler auftritt. Unabhängig davon würde ich trotzdem Float aus dem Spiel raushalten.

Wenn du decimal in der Datenbank gespeichert hast wird das beim Abrufen (zumindest in PHP) zu float und du hast Misch-Masch.

Nein, DECIMAL- und FLOAT-Spalten-Werte kommen bei PDO und mysqli als String zurück.

Interessant ist noch die Frage der Interpretation der Nutzereingaben. Weil man sowohl deutsche als auch englische Dezimaltrennung berücksichtigen muss.

Das muss man dann definieren, je nach Anwendungsgebiet (im geografischen Sinne). Da eine Ratefunktion zu schreiben, halte ich nicht für sonderlich sinnvoll. Zu viel Aufwand für alle möglichen Fälle und fehlerfrei bekommt man das nicht. Dann lieber reginalabhängig (wie auch immer man das ermittelt oder festlegt) die Tausender und Dezimalzeichen abfragen (da gibts Datensammlungen, vor allem in den Frameworks) und das eine löschen, das andere zum Punkt normalisieren.

dedlfix.