SQL - Insert mit select berechnung eines Wertes

[BenderD]

... ist (leider) nur fast richtig:
wichtig ist zuerst, ob SQL ganzahlig oder mit Nachkomma rechnet und das entscheidet sich an der ersten Rechenoperation im staement:
select 1/3 + 4 from sysibm.sysdummy1 liefert 4
select 1/3 + 4.0 ... immer noch 4
select 1/3.0 + 4 ... jetzt 4.33333
nachträglicher cast, round und Zuweisung an ein entsprechend dimensioniertes Feld hilft hier nix mehr (Zuweisung hat niedrigste Prio)
Unangenehmer Nebeneffekt hier ist, dass die Reihenfolge der Rechenoperationen vo, Statement abhängen kann (Optimizer).

Analoges gilt für Gleitkomma Berechnungen; da man hier nicht wirklich steuern kann wo die Genauigkeit hingelegt wird, sollte man das bei kaufmännischen Anwendungen immer meiden.

Beim runden muss man noch im Auge haben, dass man vor Aggregation rundet, sonst sind die Summen auf verschiedenen Aggregationsstufen nicht konsitent!

Dasselbe gilt bei Berechnungen, die auf Dreisatz beruhen (Menge mal Preis/Einheit etc.), sowie beim Aufschlag von Märchensteuer (ist hier kein SQL Phänomen).

Literale in Berechnungen vermeiden, besser Werte aus einer Parameterdatei holen und dazu joinen, oder jedes Literal casten, damit man sicher den Datentyp kennt.

D*B

Wichtig bei den ganzen Rechnereien ist die Berechnung der Anzahl Nachkomma.
Sind in der Formel (innerhalb einer Klammerebene) ausschließlich Ganzzahlen beteiligt, wird eine Ganzzahlenarithmetik verwendet. Diese ergibt niemals Nachkomma.
Bei der Verwendung von Konstanten kann man Nachkomma erzwingen wenn man eben welche angibt.
An Stelle also "/ 100" kodiert man "/ 100,00". Wenn man Multiplikation verwendet kann wird es eindeutiger und schneller (macht schon ein paar Nanos aus).
Sind alle beteiligten Ganzzahlen reicht der cast einer einzigen Variablen.
Statt also "a / b" dann eben "a / dec(b, 11, 2)".
SQL berechnet dann eben die Anzahl Gesamtstellen bis halt hin zu dec(Ausdruck, 31, n) unter möglicher Beibehaltung der Genaugkeiten.
Hier kann man (ähnlich wie in ILERPG) mit Zwischenrundungen und casts das Ergebnis beeinflussen:
"dec(round(a / dec(b, 11, 2), 2), 11, 2"
Round rundet nur kaufmännisch ohne das Format anzupassen, die Nachkomma werden also nicht gekürzt. Die Zwischenanpassung ist auch manchmal erforderlich, wenn SQL an seine Grenzen stößt und mehr als 31 Stellen benötigt werden. Dies kann man zwar mit SQL-Optionen auf 63 erhöhen, löst aber das Problem meist nicht.

Nach Möglichkeit sollte man den cast auf Double vermeiden. Man kann damit bei 10^+/-308 rechnen aber die Genauigkeit bleibt bei 14 Stellen!
Und gerade bei den Nachkommastellen fangen die Rundungsprobleme an, denn round(double(0,333), 2) ergibt leider ungefähr 0,33000000000012 und damit wird dann weiter gerechnet.