Prijs is van type float.
Ik lost dit natuurlijk op via number_format. Ik wil enkel weten waarom en hou betrouwbaar is rekenen met sql.
Jan
?
Onbekende gebruiker
17-04-2021 11:09
gewijzigd op 17-04-2021 11:22
Dat is het oude probleem van hoe getallen met een 'drijvende' komma worden opgeslagen. Dit type gegeven is bepaald niet precies.
Het staat wel ongeveer in de handleiding van MySQL, met FLOAT werk je met 4 bytes ofwel 32-bit precisie, dat is te weinig om betrouwbaar met prijzen te werken. Je kunt het aantal bits verhogen naar 64 met een DOUBLE. Dat verbetert de precisie, maar het probleem blijft, geeft MySQL toe.
Als je de details wilt weten kan je het artikel What Every Computer Scientist Should Know About Floating-Point Arithmetic lezen. Je bent niet de enige die er last van heeft, iedereen heeft er last van, zelfs Excel.
De oplossing is om prijzen en alles wat precies moet blijven op te slaan met het datatype DECIMAL of NUMERIC. Bijvoorbeeld met DECIMAL(12,3) kan je 12 cijfers opslaan, waarvan de laatste 3 achter de komma. Dat is en blijft precies, exact wat je moet hebben voor prijzen en boekhoudkundige dingen.
[size=xsmall]Toevoeging op 17/04/2021 11:13:06:[/size]
Nog even aangaande het 'natuurlijk' oplossen met number_format().
Mijn persoonlijke voorkeur is NumberFormatter, die kan rekening houden met een locale zonder dat je setlocale() hoeft te gebruiken, zodat je nooit hoeft na te denken over conflicten tussen localen voor thread safe PHP en non-thread safe PHP.
