[MS SQL] Money vs Decimal

[Anoniem: 74990]

Tot mijn verbazing kon ik met de search niets vinden hier, dus dan maar een nieuwe post. Kan iemand mij uitleggen wat het 'beste' datatype is voor het opslaan van geld bedragen in MSSQL server?

En met 'beste' bedoel ik, wat zijn de voordelen/nadelen van money tov decimal?
Het money datatype neemt minder geheugen in beslag, dat ik het enige nadeel wat ik gevonden heb. Zijn er meer voors en tegens?

[whoami]

Het Money datatype is tot 4 posities na de komma precies, bij decimal kan je dat zelf specifieren.
Als 4 decimalen niet genoeg is voor jou, dan zal je dus zowiezo decimal moeten gebruiken.
Daarnaast wordt er bij het 'money' data type ook een currency-symbol opgeslagen afaik.

[jvdmeer]

Het Money-type is een integer, waarvan de achterste 4 cijfers achter de komma staan. Maar intern is het dus een integer. Dus bij berekeningen loop je geen kans op afrondingsfouten. 12345,- wordt dus opgeslagen als 123450000.

De decimal is een floating-point. Dus je loopt kans op afrondingsfouten. Het zou bijvoorbeeld kunnen dat 12345 wordt opgeslagen als 1.234499999E+5.

kijk zelf maar wat je belangrijker vindt. Bereik of preciesie.

[whoami]

Hmm, bij decimal zou je ook geen afrondingsfouten mogen hebben.

Numeric data types with fixed precision and scale

[EfBe]

jvdmeer schreef op 16 september 2004 @ 10:53:
Het Money-type is een integer, waarvan de achterste 4 cijfers achter de komma staan. Maar intern is het dus een integer. Dus bij berekeningen loop je geen kans op afrondingsfouten. 12345,- wordt dus opgeslagen als 123450000.

De decimal is een floating-point. Dus je loopt kans op afrondingsfouten. Het zou bijvoorbeeld kunnen dat 12345 wordt opgeslagen als 1.234499999E+5.

kijk zelf maar wat je belangrijker vindt. Bereik of preciesie.

Erm... beide zijn een 'decimal' en geen integer noch een floating point. Decimals worden in BCD format opgeslagen, 4 bits per digit. Dit zie je ook aan de decimal definitie. Een decimal met precision van 18 heeft een length van 9 (bytes). De scale definitie bepaalt dan waar de punt staat. Je hebt dus helemaal geen afrondingsfouten, want het is niet opgeslagen als IEEE float.

Een money type heeft een vaste size van 8 bytes, een precision van 19 en een scale van 4.

Een float van 8 bytes heeft een precision van 53. Dat zijn nogal wat meer digits dan een money type aankan met zn 8 bytes.

[jvdmeer]

EfBe schreef op 16 september 2004 @ 12:37:
[...]

Erm... beide zijn een 'decimal' en geen integer noch een floating point. Decimals worden in BCD format opgeslagen, 4 bits per digit. Dit zie je ook aan de decimal definitie. Een decimal met precision van 18 heeft een length van 9 (bytes). De scale definitie bepaalt dan waar de punt staat. Je hebt dus helemaal geen afrondingsfouten, want het is niet opgeslagen als IEEE float.

Een money type heeft een vaste size van 8 bytes, een precision van 19 en een scale van 4.

Een float van 8 bytes heeft een precision van 53. Dat zijn nogal wat meer digits dan een money type aankan met zn 8 bytes.

Wat betreft precisie klopt het. Decimal is inderdaad ook vrij van afrondingsfouten, echter het wordt niet in BCD opgeslagen maar gewoon binair.

Uit Transact-SQL Reference:

Precision	Storage bytes
1- 9	5
10-19	9
20-28	13
29-38	17

en als we dat dan controler voor een preciezie van 38:

code:

ln ((10^39)-1)        89,8008
--------------  / 8 = ------- /8 = 129,5552 / 8 = 16,2 bytes oftewel 17
     ln 2              0,6931

en als we dat dan controler voor een preciezie van 19:

code:

ln ((10^20)-1)        46,0517
--------------  / 8 = ------- /8 = 66,4386 / 8 = 8,3 bytes oftewel 9
     ln 2              0,6931

[ Voor 17% gewijzigd door jvdmeer op 16-09-2004 13:34 . Reden: tabelletje gemaakt ]

[EfBe]

Ik volg je berekeningen niet echt, maar ik vind het wel vreemd dat voor 19 cijfers ze 9 bytes nodig hebben. 9 bytes zijn 72 bits, je kunt daar dus (2^72)-1 in opslaan, binair, oftewel, een precision van 22, niet 19 (ok, niet helemaal precision 22, want het maximale getal is (unsigned) 4722366482869645213695). Met BCD, kun je dus in 9 bytes een 18 precision getal kwijt. Ik begreep inderdaad niet echt waarom bij een precision van 20 in ineens 13 bytes nodig had, 13 bytes kan een getal bevatten van precision 32.