Firebird und Numeric fields

[himitsu]

In 18.4 passt z.B. folgende Zahl 12.345.678.901.234,5789 und das sind immerhin nur in etwa 3,5 Milliarden Euro. (bis zu 28 Mrd.€)
Wenn dir das nicht reicht, dann kannst du es auch problemlos als Nummeric(999999.4) speichern.

Numeric(18.4) würde aber zumindestens dem Typ Currency im Delphi entsprechen, falls man auch da problemlos rundungssicher arbeiten/rechnen will.

Zitat:

da mir floats oft Probleme bereiten mit Menge

Darum sollte man auch im Delphi bei sowas vielleicht besser mit Currency arbeiten und bei Floats niemals auf gleich/identisch Prüfen.

[MyRealName]

Numeric(9999,4) geht nicht, geht in firebird scheinbar "nur" bis 18.
Eigentlich wollte ich ja numeric(18.4) für alle Currency-Felder, aber jede mathematische Op in firebird erzeugt daraus ein 18,8... dann passen da nur noch 1.234.567.890,12345 rein, also man grad 310k euro in Pesos.

und das problem habe ich nicht in Delphi, osndern nur in Firebird. In Delphi kann cih mit Currency für geld arbeiten und bei Inventar-Mengen mit extended und CompareValue.

[Lemmy]

Zitat von MyRealName:

Eigentlich wollte ich ja numeric(18.4) für alle Currency-Felder, aber jede mathematische Op in firebird erzeugt daraus ein 18,8...

bei mir nicht.. welche Firebirdversion hast Du denn? Die 2.1 macht das problemlos mit:

Code:

CREATE TABLE Test (
test1 Numeric(18,4),
test2 Numeric(18,4),
test3 Numeric(18,4));


INSERT INTO test VALUES (2.5, 5, 0);

UPDATE test SET test3=Test1*test2;

Und selbst wenn das in neueren Firebird geändert wurde, was spricht denn gegen ein

Code:

Select cast(test1*test2 AS Numeric(18.4)) from test

Grüße

[MyRealName]

Zitat von Lemmy:

Zitat von MyRealName:

Eigentlich wollte ich ja numeric(18.4) für alle Currency-Felder, aber jede mathematische Op in firebird erzeugt daraus ein 18,8...

bei mir nicht.. welche Firebirdversion hast Du denn? Die 2.1 macht das problemlos mit:

Code:

CREATE TABLE Test (
test1 Numeric(18,4),
test2 Numeric(18,4),
test3 Numeric(18,4));


INSERT INTO test VALUES (2.5, 5, 0);

UPDATE test SET test3=Test1*test2;

Und selbst wenn das in neueren Firebird geändert wurde, was spricht denn gegen ein

Code:

Select cast(test1*test2 AS Numeric(18.4)) from test

Grüße

http://www.firebirdfaq.org/faq79/

Zitat:

Here's an example: if you multiply 9.12 with 8.11 (both numeric(18,2)) you would get 73.9632. If Firebird would store that into numeric(18,2) datatype, we would lose 0.0032. Doesn't look much, but when you have complex calculations, you can easily loose thousands (dollars or euros). Therefore, the result is stored in numeric(18,4).

[himitsu]

A * B * C * D * E * F * G * H -- alles numeric(18.2) ergibt dann also numeric(18.16) ?

Ich hätte eher erwartet, dass hinten das raus kommt, was als "größter" Typ rein ging.

[MyRealName]

Zitat von himitsu:

A * B * C * D * E * F * G * H -- alles numeric(18.2) ergibt dann also numeric(18.16) ?

Ich hätte eher erwartet, dass hinten das raus kommt, was als "größter" Typ rein ging.

Ich auch, aber das ist, was bei firebird auf der Seite steht...

Mein Ansatz im MOment ist es, dass ich es händisch vielleicht selbst mache... alles mit 10.000 multiplizieren und in einem Bigint speichern und damit rechnen und dann alles durch 10.000 dividieren und dann in ein Numeric(18,4)

[hstreicher]

Zitat von himitsu:

A * B * C * D * E * F * G * H -- alles numeric(18.2) ergibt dann also numeric(18.16) ?

Ich hätte eher erwartet, dass hinten das raus kommt, was als "größter" Typ rein ging.

ja, so kommt das raus , ist aber glaube ich SQL Standard
das Problem löst man mit einer Cast "Orgie" um die Overflows die sich bei längeren Berechnungen ergeben abzufangen

also

Code:

cast(cast(cast(a*b as numeric(18,4))*c as numeric(18,4))*d as numeric(18,4))

http://www.firebirdsql.org/file/comm..._datatypes.pdf

[IBExpert]

innerhalb zB der Euro Welt oder beim US$ kommt man mit fest defininerten 2 Nachkommastellen eigentlich schon ganz gut klar im Bereich Währungsangaben, bei Mengenangaben ist das je nach Branche und Mengeneinheit aber schon ganz anders. Im Bereich industrieller Kalkulation sind da schon gerne mal 3-4 Nachkommastellen erforderlich, daher ist eigentlich Numeric(18,4) schon der passende Typ (der war aber pysikalisch im Dialekt 3 in einem Bigint gespeichert.

Vielleicht hilft es dir aber, einfach mal auch in Firebird den Typ "DOUBLE PRECISION" zu nehmen, dessen Verhalten ziemlich identisch zum Double in Delphi ist.
Um den dann mit definierter Anzahl Nachkommastellen darzustellen, kannst du dir ja bei Firebird 3 eine eigene Stored function bauen, die deine Währungseinstellung berücksichtigt oder konstant einfach mit ROUND() oder cast arbeiten

[Lemmy]

Zitat von MyRealName:

http://www.firebirdfaq.org/faq79/

Zitat:

Here's an example: if you multiply 9.12 with 8.11 (both numeric(18,2)) you would get 73.9632. If Firebird would store that into numeric(18,2) datatype, we would lose 0.0032. Doesn't look much, but when you have complex calculations, you can easily loose thousands (dollars or euros). Therefore, the result is stored in numeric(18,4).

ähm. ja.. Logisch. Technisch bedingt aber eine Multiplikation von Numeric(18,4) kein Ergebnis mit mehr Nachkommastellen. Das kann max. eine fachliche Anforderung sein, davon hast Du leider nix geschrieben. Und ja, es gibt Anwendungsfälle, bei denen man zwingend die Zwischenergebnisse auf 2 Nachkommastellen rundet.

[mensch72]

mal unabhängig von der Frage, ob es real überhaupt "0,xx COP" gibt, stellt sich die Frage warum eine solche Software nicht intern und in der DB mit einer "passenden" normalisierten Einheit programmiert wird?

Wir arbeiten im Finanzbereich intern seit der Euro Einfühung quasi mit dem "USD Fixing zu diesem Zeitpunkt" für alles und jedes als unsere interne "UniversalExchangeUnit" abgekürzt "UEU".
Bei Zeiten speichern und rechnen wir nur in UTC... Wenn in Japan oder Kolumbien sich jemand was aktuell BTC mit 0,0000xxxxxx eingibt oder anzeigt, ist das nicht viel anders wie wenn er es für was wertvolle wie Gold XXXX,xxx tun würde.
(Wenn Kunden mit den Augen rollen, weil sie mit den internen Daten in unserer DB nix anfangen können, bekommen sie als Dienstleistung passende "ReadOnly" Views und können sich je nach Gusto dann an ihren "NullNullXvalues" oder "BigValues" erfeuen)

Klar ist das eine Konzeptfrage, aber bei sauberer Trennung von GUI<->DB<->BussinesLogic sollte das doch kein Problem sein. Dann reichen in der DB auch Numeric/BCD und in Delphi "Currency/FixComma".

Und Astronomen sowie Pysiker machen es doch auch so clever... die verrechnen normalisierte Werte und Einheiten getrennt und normalisieren zum Schluss nochmal das Ergebnis auf eine passende Basiseinheit mit sinnvoller Genauigkeit.
Das machten die schon mit Rechnenschiebern so und machen es auch heute mit Computern noch so... die versuchen garnicht erst eine Zahl im Wertebereich bis 10^ +18 auch noch mit einer Genauigkeit auf 10^ -18 zu definieren... die haben&nutzen entweder das eine oder das andere, und bleiben so immer in ihrer konstanten Genauigkeit (hier im Beispiel 18Stellen), egal ob tausend Stellen vor dem Komma, oder tausend Stellen hinter dem Komma.