December 20, 2012 at 5:57 am
Hi,
I've a table that stores currency amount values and is used in some calculations (vat, discounts, ....).
FLOAT, REAL, MONEY and SMALLMONEY can have round issues due to their internal storage method in SQL Server being DECIMAL the only one that hasn't that issue.
What's the best mapping from each type to DECIMAL?
Should FLOAT and MONEY use the default DECIMAL precision (18) and REAL and SMALLMONEY 9 ?
Thanks,
Pedro
December 20, 2012 at 7:27 am
Technically FLOAT, REAL, MONEY and SMALLMONEY all have different ranges, but my standard is just to convert all numeric values of different types, especially values with currency, to Numeric(17,2), and for percents I use Numeric(17,6). Doing this keeps all numeric values standard across the database.
Also Numeric and Decimal are equivalents, I just have always used Numeric, but you can use Decimal just the same.
Hope this helps ..
Sam
December 20, 2012 at 8:22 am
samalex (12/20/2012)
Technically FLOAT, REAL, MONEY and SMALLMONEY all have different ranges, but my standard is just to convert all numeric values of different types, especially values with currency, to Numeric(17,2), and for percents I use Numeric(17,6). Doing this keeps all numeric values standard across the database.Also Numeric and Decimal are equivalents, I just have always used Numeric, but you can use Decimal just the same.
Hope this helps ..
Sam
You could use NUMERIC(19,2) and NUMERIC(19,6) as your standards, since they use the same amount of storage, 9 bytes, as NUMERIC(17,2) and NUMERIC(17,6).
December 21, 2012 at 6:33 am
Comparing FLOAT and REAL to DECIMAL and NUMERIC is not really fair. The former are approximate numeric data types and the latter are exact numeric data types. I am leaving MONEY and SMALLMONEY out of it because those should never be used. For example if you're currently using FLOAT and REAL to sum the precent-segments of a set where the percentage sum should equal 100.00 then if you switch to an exact data type you will start having issues, e.g. coming up with 99.76 or some non-trivial amount away from 100.00. Just throwing it out there, be sure you test to ensure you have chosen the right data type for the job.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
December 21, 2012 at 8:12 am
opc.three (12/21/2012)
Comparing FLOAT and REAL to DECIMAL and NUMERIC is not really fair. The former are approximate numeric data types and the latter are exact numeric data types. I am leaving MONEY and SMALLMONEY out of it because those should never be used. For example if you're currently using FLOAT and REAL to sum the precent-segments of a set where the percentage sum should equal 100.00 then if you switch to an exact data type you will start having issues, e.g. coming up with 99.76 or some non-trivial amount away from 100.00. Just throwing it out there, be sure you test to ensure you have chosen the right data type for the job.
My main problem wanting to change to DECIMAL is that we deal with money values and store the value with out VAT, therefore it can be a long decimal value...
But cause we store it in float the invoice report, occasionally, gives different values for the total since each line is VALUE + VAT and the total is SUM(VALUE) + VAT and sometimes they are different due to the floating point issue, and also we had 2 reports with different values (cents but different...).
Thanks,
Pedro
December 21, 2012 at 9:06 am
For $ I would recommend an exact numeric data type with the scale you need to satisfy your accounting requirements.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply