Aloha ;)

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.

Das stimmt mMn so nicht ganz. Ein Rundungsfehler tritt an dieser Stelle (zumindest mathematisch begründbar) nicht auf. float-Werte werden nur für die Ausgabe (!) genutzt. Die Eingabe muss ja so oder so interpretiert werden. Außerdem ist die Eingabe immer exakt. Jetzt ist es also aufgrund meines Lösungsdesigns (Integer überall außer zur Ausgabe) so, dass mit float-Beteiligung nur folgende beide Operationen passieren:

float * 100    und     int / 100

Rundungsfehler, die du hier zitierst, treten in diesem Fall aber (zumindest mathematisch gesehen aufgrund der Gleitkommaarithmetik) überhaupt nicht auf. Wenn ich hier einen Rundungsfehler bekäme, dann nur deshalb, weil der gewählt Datentyp zu wenig Bits zur Verfügung hat, der Wert also nicht im Scope liegt. Nein, die Flinte mit der Ungenauigkeit liegt woanders im Korn. Nämlich sobald ich mit floats bestimmte problematische Operationen ausführe. Dazu zählen: Subtraktionen, Additionen, Vergleichsoperationen, Äquvialenzumformungen nach Assoziativ- und Distributivgesetz. Multiplikationen gehören insbesondere nicht dazu, solange keine Scope-bedingten Rundungsfehler auftreten. Außerdem sprechen wir bei diesen Ungenauigkeiten von Effekten, die sich erst nach mehrmaligen Operationen kumulieren und dadurch sichtbar werden. Das ist zumindest das, was mathematisch bei Fließkommaarithmetik passiert. Ob in diversen Programmiersprachen noch zusätzliche Problematiken aufgrund schlechter Implementierung auftreten, kann ich nicht beurteilen.

Aber das ist eventuell alles auf die Begründung bezogene Erbsenzählerei, denn...

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. [...] Unabhängig davon würde ich trotzdem Float aus dem Spiel raushalten.

In diesem Fall stimme ich dir natürlich zu: Die von dir genannte Methode ist sicher die Bessere. IMHO hast du insgesamt Recht, nur die Begründung oben war mMn (zumindest so wie ich sie verstanden hatte) nicht die richtige.

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.

Ja, schon. Und wenn ich dann damit rechnen möchte tu ich was? Dann habe ich wieder nur die zwei Möglichkeiten, es als float oder integer zu Interpretieren, um die Werte weiterverarbeiten zu können (denn mit Strings rechnet es sich schwerlich). Daher mein flapsiges "wird das beim Abrufen zu float". Denn wenn ich es nach dem Abrufen direkt als Integer interpretiere hätte ich es doch auch direkt als Integer speichern können.

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.

Findest du? Ich weiß nicht, aber ich bin ziemlich sicher, dass meine oben gepostete Ratefunktion exakt arbeitet. Ich bin da eher Freund von Toleranz, was das Akzeptieren von Nutzereingaben angeht (natürlich nur, solange es soweit als möglich eindeutig interpretierbar bleibt). Die User werden von gängigen Programmen schon oft genug hin und her geworfen (manche akzeptieren deutsche Schreibweise, manche nicht - wissen tut mans oft erst, wenn das Programm den ersten Fehler spuckt). Ich fand im Gegenteil meine Überprüfung eigentlich ziemlich vollständig. Zumindest alle von mir geposteten Beispiele lassen sich damit sinnvoll interpretieren und mir mag kein Gegenbeispiel einfallen.

Natürlich könnte der User statt 140,00 meinen: 140,000 -> 140 000 00 ct und nicht 140 00 ct. Dieses Problem (vergessene Stellen) ist aber nie verhinderbar - er könnte ja genauso gut schreiben 140 00 statt: 140 000 und niemandem würde es auffallen. Das ist also imho verschmerzbarer, als dem User eine Schreibweise aufzudrücken, wenn es auch anders geht.

Grüße,

RIDER