Thread: What data type best used for money

THINK BEFORE YOU PRINT - Save paper if you don't really need to print this e-mail.

*******************Confidentiality and Privilege Notice*******************

The material contained in this message is privileged and confidential to the addressee. If you are not the addressee indicated in this message or responsible for delivery of the message to such person, you may not copy or deliver this message to anyone, and you should destroy it and kindly notify the sender by reply email.

Information in this message that does not relate to the official business of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta. Weatherbeeta, its employees, contractors or associates shall not be liable for direct, indirect or consequential loss arising from transmission of this message or any attachments

niccguard-dev@yahoo.com wrote:
> Creating a database where monetary values will be stored and of course
> retrieved with calculations.  What data types are best to use in this
> sort of environment?
>
> money is limited in quantity
>
> numeric - documentation states "arithmetic on numeric values is very
> slow compared to the integer types"
>
> Just wanted to get some feedback on what seems to be the better way to
> go and 'why'.

A good explanation of the "why" for using numeric/decimal data types in
various situations:

    http://www2.hursley.ibm.com/decimal/decifaq.html

Money should really (imho) be stored as numerics. Storing as an integer
sounds good at first, but that makes it much too tempting for someone
who doesn't know better to do floating point math against those integers
and just drop the remainders (e.g. tax calculations, currency
conversions and anything else dealing with fractions of pennies). That
might not produce a bad number when done against a single row at a time,
but when you start doing aggregate reporting against many rows, those
tiny little floating point errors can potentially add up and throw you
off by enough to cause your accountants/auditors to start harassing you.

Unless, of course, you determine the highest precision any of your
calculations will ever need and pad your integer columns out to that and
do everything as integer calcs. But what happens when you find you need
one more digit of precision, and to support that you have to literally
go through and append a zero to the end of every single "money" number
in your entire database? Or how about all the places you'll need to
remember to format these numbers to their appropriate decimal form for
display, and conversely "unformat" all numbers input by users or other
applications that are headed for storage in the DB?

-Jon

--
Senior Systems Developer
Media Matters for America
http://mediamatters.org/