[MYSQL] Große Fließkommazahlen

[FredRedHead]

Hallo,
ich habe ein Problem bei der Speicherung von Fließkommazahlen.
Wenn ich mein MYSQL-field typ mit float(17,2) bezeichne und 99999999.00 eingebe, wird 100000000.00 gespeichert. Wenn ich 100005000.00 speichere, wird 100005000.00 gespeichert (richtig).. wenn ich 100000004.00 eingebe, dann wird 100000000.00 gespeichert. Nun ist das Problem, dass auch mal halbe Punkte gutgeschrieben werden bzw. ein User auch mal 99999999.50 haben könnte.. dies wird aber nicht gespeichert!!

Wie umgehe ich dieses Problem bzw. wie speichert man große Fließkommazahlen?
Möchte gerne 100 Mio und ein paar zerquetschte Lose speichern

 

[DocTrax]

Hallo,
ich habe ein Problem bei der Speicherung von Fließkommazahlen.
Wenn ich mein MYSQL-field typ mit float(17,2) bezeichne und 99999999.00 eingebe, wird 100000000.00 gespeichert. Wenn ich 100005000.00 speichere, wird 100005000.00 gespeichert (richtig).. wenn ich 100000004.00 eingebe, dann wird 100000000.00 gespeichert. Nun ist das Problem, dass auch mal halbe Punkte gutgeschrieben werden bzw. ein User auch mal 99999999.50 haben könnte.. dies wird aber nicht gespeichert!!

Wie umgehe ich dieses Problem bzw. wie speichert man große Fließkommazahlen?
Möchte gerne 100 Mio und ein paar zerquetschte Lose speichern

Man nehme bigint - muss dann halt mit vor dem speichern mit 100 multiplziert und beim auslesen mit 100 dividiert werden.

 

[FredRedHead]

Man nehme bigint - muss dann halt mit vor dem speichern mit 100 multiplziert und beim auslesen mit 100 dividiert werden.

ja, dachte aber es gäbe was einfacheres

 

[DocTrax]

ja, dachte aber es gäbe was einfacheres

Die Mantisse ist auch integer.

 

[n00ne]

decimal(12,2)

 

[DocTrax]

Ich zitere mal die Anleitung:

FLOAT[(M,D)] [ZEROFILL]

Eine kleine Fließkommazahl (einfacher Genauigkeit). Kann nicht vorzeichenlos sein. Der Wertebereich umfasst -3.402823466E+38 bis -1.175494351E-38, 0 und 1.175494351E-38 bis 3.402823466E+38. M ist die Anzeigebreite und D ist die Anzahl von Dezimalstellen. FLOAT ohne Argument oder mit einem Argument <= 24 steht für eine Fließkommazahl einfacher Genauigkeit.


DECIMAL[(M[,D])] [ZEROFILL]

Eine unkomprimierte Fließkommazahl. Kann nicht vorzeichenlos sein. Verhält sich wie eine CHAR-Spalte: ``Unkomprimiert'' bedeutet, dass die Zahl als Zeichenkette gespeichert wird, wobei ein Zeichen für jede Ziffer des Wertes steht. Der Dezimalpunkt und, bei negativen Zahlen, das ‘-’-Zeichen, werden in M nicht mitgezählt (aber hierfür wird Platz reserviert). Wenn D 0 ist, haben Werte keinen Dezimalpunkt oder Bruchteil. Der maximale Wertebereich von DECIMAL-Werte ist derselbe wie für DOUBLE, aber der tatsächliche Wertebereich einer gegebenen DECIMAL-Spalte kann durch die Auswahl von M und D eingeschränkt sein.

Wenn D weggelassen wird, wird es auf 0 gesetzt. Wenn M ausgelassen wird, wird es auf 10 gesetzt.

Beachten Sie, dass in MySQL-Version 3.22 das M-Argument den Platz für das Vorzeichen und den Dezimalpunkt beinhaltete!

Also kann man statt decimal auch varchar nehmen.

 

[theHacker]

Da hier Millilose etc. gespeichert werden sollen, könnte vielleicht auch sowas eine Alternative darstellt:

[FONT=Courier New]Lose [B][COLOR=DarkOrchid]INT[/COLOR][/B][COLOR=DarkOrchid]([/COLOR]11[COLOR=DarkOrchid])[/COLOR] [B][COLOR=DarkOrchid]NOT NULL[/COLOR][/B]
Mikrolose [B][COLOR=DarkOrchid]INT[/COLOR][/B][COLOR=DarkOrchid]([/COLOR]11[COLOR=DarkOrchid])[/COLOR] [B][COLOR=DarkOrchid]NOT NULL[/COLOR][/B][/FONT]

Du speicherst damit z.B. 2565,62 Lose als (Lose, Mikrolose) VALUES (2565,620000) ab.

Es können sowieso nur ganze Lose ausgezahlt werden.
Ob es wirklich rentabel ist, musst du unter Berücksichtigung deines gesamten Scripts entscheiden.

 

[FredRedHead]

Ob es wirklich rentabel ist, musst du unter Berücksichtigung deines gesamten Scripts entscheiden.

genau das ist das problem. es müsste zu viel geändert werden, deshalb habe ich nun auf ganze lose umgestellt.. basta

 

[theHacker]

genau das ist das problem. es müsste zu viel geändert werden, deshalb habe ich nun auf ganze lose umgestellt.. basta

Realitisch gesehen, am Wert von einem Los betrachtet, braucht man niemals einen Wert kleiner als 1 Los.