Currency oder Double

[mm1256]

Zitat von p80286:

!currency!
Ohne Currency gab es im Zusammenspiel von DB, Frontend und erstellten Briefen (Word mit ein paar Macros) immer wieder Abweichungen im Cent-Bereich, die nervig bis peinlich waren.
Jetzt herrscht Ruhe!

Gruß
K-H

Kann es sein, dass diese Abweichungen auch was mit der Datenbank zu tun haben? Ich verwende NexusDB - die ja bekanntlich in Delphi programmiert ist - und hatte diesbezüglich noch keine Probleme.

[Dejan Vu]

Also floating point ist floating point, egal wer mit wem und wo das programmiert wurde. Wenn Nexus-DB hier kein FP nimmt, sondern BCD, dann wäre das ja mal was, wobei 'Numeric(x,y)' zumindest in SQL-Server auch eine BCD ist.

FP und Währungen sind eine Qual. Wir haben ein Bankensystem, bei dem die Honks, die das programmiert haben, alle Währungen in der DB als 'float' abgebildet haben (SQL-Server) und nun müssen sie in jeder 2.Zeile die Werte krampfhaft runden. Und selbst dann kann ich von einem Konto, auf dem noch 9.99 Euro drauf sind, nicht immer 9.99 Euro abheben, weil der Dispo auf 0.00 ist und -0.0000000000000000123 eben weniger als 0.00 sind.

Zu den Argumenten: "Bei mir ist noch nie was passiert" fällt mir immer nur der Autofahrer ein, der ohne Sicherheitsgurt fährt, und das gleiche sagt.

Wegen interner Berechnungen von Zinsen etc. verwenden wir BCD, da ist Currency leider nicht genau genug. Aber in er DB würde ich nur noch 'money' verwenden. In der Darstellungsschicht würde ich allerdings auf Currency setzen, weil das irgendwie dem nahe kommt, was man darstellen will.

Vor Jahren haben wir mal eine Logistik- und Abrechnungssoftware mit Double gebaut, das war ähnlich krank. Da hatten wir zwar keine Probleme in der DB, aber dafür bei der Rechnungslegung. Was da für Rundungsprobleme entstanden sind, verstehe ich bis heute nicht, aber sie waren da.

[Lemmy]

Zitat von Dejan Vu:

FP und Währungen sind eine Qual. Wir haben ein Bankensystem, bei dem die Honks, die das programmiert haben, alle Währungen in der DB als 'float' abgebildet haben (SQL-Server) und nun müssen sie in jeder 2.Zeile die Werte krampfhaft runden. Und selbst dann kann ich von einem Konto, auf dem noch 9.99 Euro drauf sind, nicht immer 9.99 Euro abheben, weil der Dispo auf 0.00 ist und -0.0000000000000000123 eben weniger als 0.00 sind.

Drollig wird es dann, wenn die Programmierer angewackelt kommen und fragen, warum da -0.0000000000000000123 raus kommt - weil sie runden ja vorher (einen Double auf einen Double)...

Zitat von Dejan Vu:

Zu den Argumenten: "Bei mir ist noch nie was passiert" fällt mir immer nur der Autofahrer ein, der ohne Sicherheitsgurt fährt, und das gleiche sagt.

das hinkt... Das Problem ist doch: Es passiert immer wieder, nur fällt es nicht auf. Wie bei der Software die ich in meinem letzten Post beschrieben habe: Über Jahrzehnte wird da mit Double gerechent - die Unterschiede (und Rechenfehler) sind erst dann aufgefallen, als ich die gleichen Daten in eine XML schreiben musste - da aber halt als Cent-Betrag ohne Nachkommastellen und auf einmal hat sich Papierrechnung und XML unterschieden....

[Dejan Vu]

[QUOTE=Lemmy;1294082das hinkt... [/QUOTE] Das Wesen eines guten Vergleiches ;-()
Du kannst auch mal ohne Gurt auf deinen Vordermann stupseln. Aber klar. Im Grunde genommen ist die Einstellung, ohne Gurt ginge es auch, etwas fataler in der Auswirkung als 'Double als Währung'.

Grad gestern hat der 'Lead Developer' hier gemeint, wir sollten doch bitte auch in neuen Funktionen mit 'Float' und 'Double' arbeiten, sonst würde man ja ganz konfus..

[bernau]

Zitat von Lemmy:

Drollig wird es dann, wenn die Programmierer angewackelt kommen und fragen, warum da -0.0000000000000000123 raus kommt - weil sie runden ja vorher (einen Double auf einen Double)...

Ja, ein Double ist ein Double. Und wenn ich weis, wie ich mit einem Double umgehen muss, dann passiert mir so etwas nicht.

Das soll jetzt kein Fürsprecher für Double sein. Aber auch mit Currency gibt es bestimmt auch Fallstricke. Man muss ich eben mit dem Zahlentyp auskennen.

[Dejan Vu]

Erstmal richtig: Auskennen muss man sich.

Bei Double wird aus klaren Anweisungen dann leider idiotischer und unverständlicher Code.
Beispiel:
Vorgabe: Abheben darf ich einen Betrag X, wenn der auf dem Konto verbleibende Betrag nicht kleiner als der Dispo ist. Oder einfacher: Die Bedingung lautet 'Betrag - X >= Dispo'. Das möchten wir bitte so im Code umsetzen. Aber was muss ich stattdessen machen? 'Abs(Betrag - X - Dispo) >= Epsilon'! WTF?

[bernau]

Zitat von Dejan Vu:

Erstmal richtig: Auskennen muss man sich.

Bei Double wird aus klaren Anweisungen dann leider idiotischer und unverständlicher Code.
Beispiel:
Vorgabe: Abheben darf ich einen Betrag X, wenn der auf dem Konto verbleibende Betrag nicht kleiner als der Dispo ist. Oder einfacher: Die Bedingung lautet 'Betrag - X >= Dispo'. Das möchten wir bitte so im Code umsetzen. Aber was muss ich stattdessen machen? 'Abs(Betrag - X - Dispo) >= Epsilon'! WTF?

Dafür kann man sich schöne sprechende Funktionen schreiben

[Dejan Vu]

Zitat von bernau:

Dafür kann man sich schöne sprechende Funktionen schreiben

If IsLessThan(X-Y,Z) then ist ja auch viel besser lesbar als If X-Y<Z then .. oder war das doch anders herum?

Ach ja, und immer (auf)runden. Und aufpassen. Immer aufpassen. Und hier noch ein Runden und da noch eins.

Also ich nehm lieber den einfachen Weg und nimm kein Double.