Ik zou het als DECIMAL doen, dan hoef je niet steeds te hannesen met de conversie naar centen. Het ligt er een beetje aan welk type INT je precies pakt, maar meestal zijn die paar bytes meer of minder het probleem ook niet.
Oké, ik dacht dat er een bepaald voordeel was om een bedrag op te slaan in centen. Ik meen dat dat te maken had met het afronden van bedragen of zo, maar ik weet het niet meer zeker.
Mee eens. Maar een integer die dan het bedrag in centen opslaat doet het ook. Wat heeft je voorkeur?
[size=xsmall]Toevoeging op 10/03/2019 23:26:34:[/size]
p.s. in sommige branches worden nog tienden van centen gebruikt en misschien ook nog wel honderdsten of duizendsten.. In dat geval ligt een DECIMAL meer voor de hand
>> p.s. in sommige branches worden nog tienden van centen gebruikt en misschien ook nog wel honderdsten of duizendsten.. In dat geval ligt een DECIMAL meer voor de hand
Het gaat gewoon om normale bedragen met 2 cijfers achter de komma.
Wat is het voordeel als ik het als centen opsla via een INT in plaats van als DECIMAL?
>> (ook) De(ze) vraag is niet eenduidig te beantwoorden zonder een concrete toepassing.
Heel concreet ... ik wil een normale prijs in euro's kunnen invoeren van een product. De prijs heeft 2 cijfers achter de komma. Het gaat om Nederlandse prijzen.
MySQL DECIMAL data type and monetary data
We often use the DECIMAL data type for monetary data such as prices, salary, account balances, etc. If you design a database that handle the monetary data, the following syntax should be OK.
amount DECIMAL(19,2);
However, if you want to comply with Generally Accepted Accounting Principles (GAAP) rules, the monetary column must have at least 4 decimal places to make sure that the rounding value does not exceed $0.01. In this case, you should define the column with 4 decimal places as follows:
Hoi Ward, die informatie was ik zelf ook tegengekomen.
DECIMAL lijkt dus een goede keuze te zijn.
Echter, ik heb ook gehoord (wellicht hier op het forum) dat mensen de voorkeur eraan geven om het bedrag in centen op te slaan. Dus ik vraag me af of daar een voordeel aan zit (of misschien wel helemaal niet).
API's van PSP's (payment service providers) werken soms met bedragen in centen, onder andere omdat punten en komma's dan niet in de weg zitten. Ik vind dat je data zoveel mogelijk moet opslaan in datatypen die daarvoor het best geschikt zijn en vanwege de nauwkeurigheid is dat DECIMAL voor geldbedragen.
Het maakt je oplossing ook wat beter schaalbaar. Er zijn valuta met meer dan 2 decimalen en bijvoorbeeld brandstofprijzen in tienden van centen: als je die moet ondersteunen, moet je overal je berekeningen met * 100 en / 100 herschrijven (met kans op fouten) of een multiplier-constante invoeren die afhankelijk is van de gebruikte valuta (met nog meer kans op fouten).
