Home/ Questions/Q 71419
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T19:53:05+00:00

I’m using a decimal column to store money values on a database, and today

  • 0

I’m using a decimal column to store money values on a database, and today I was wondering what precision and scale to use.

Since supposedly char columns of a fixed width are more efficient, I was thinking the same could be true for decimal columns. Is it?

And what precision and scale should I use? I was thinking precision 24/8. Is that overkill, not enough or ok?

This is what I’ve decided to do:

  • Store the conversion rates (when applicable) in the transaction table itself, as a float
  • Store the currency in the account table
  • The transaction amount will be a DECIMAL(19,4)
  • All calculations using a conversion rate will be handled by my application so I keep control of rounding issues

I don’t think a float for the conversion rate is an issue, since it’s mostly for reference, and I’ll be casting it to a decimal anyway.

Thank you all for your valuable input.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. If you are looking for a one-size-fits-all, I’d suggest DECIMAL(19, 4) is a popular choice (a quick Google bears this out). I think this originates from the old VBA/Access/Jet Currency data type, being the first fixed point decimal type in the language; Decimal only came in ‘version 1.0’ style (i.e. not fully implemented) in VB6/VBA6/Jet 4.0.

    The rule of thumb for storage of fixed point decimal values is to store at least one more decimal place than you actually require to allow for rounding. One of the reasons for mapping the old Currency type in the front end to DECIMAL(19, 4) type in the back end was that Currency exhibited bankers’ rounding by nature, whereas DECIMAL(p, s) rounded by truncation.

    An extra decimal place in storage for DECIMAL allows a custom rounding algorithm to be implemented rather than taking the vendor’s default (and bankers’ rounding is alarming, to say the least, for a designer expecting all values ending in .5 to round away from zero).

    Yes, DECIMAL(24, 8) sounds like overkill to me. Most currencies are quoted to four or five decimal places. I know of situations where a decimal scale of 8 (or more) is required but this is where a ‘normal’ monetary amount (say four decimal places) has been pro rata’d, implying the decimal precision should be reduced accordingly (also consider a floating point type in such circumstances). And no one has that much money nowadays to require a decimal precision of 24 🙂

    However, rather than a one-size-fits-all approach, some research may be in order. Ask your designer or domain expert about accounting rules which may be applicable: GAAP, EU, etc. I vaguely recall some EU intra-state transfers with explicit rules for rounding to five decimal places, therefore using DECIMAL(p, 6) for storage. Accountants generally seem to favour four decimal places.

    PS Avoid SQL Server’s MONEY data type because it has serious issues with accuracy when rounding, among other considerations such as portability etc. See Aaron Bertrand’s blog.

    Microsoft and language designers chose banker’s rounding because hardware designers chose it [citation?]. It is enshrined in the Institute of Electrical and Electronics Engineers (IEEE) standards, for example. And hardware designers chose it because mathematicians prefer it. See Wikipedia; to paraphrase: The 1906 edition of Probability and Theory of Errors called this ‘the computer’s rule’ (‘computers’ meaning humans who perform computations).

    • 0