Question

I inherited a project that uses SQL Server 200x, wherein a column that stores a value that is always considered as a percentage in the problem domain is stored as its greater than 1 decimal equivalent. For example, 70% (0.7, literally) is stored as 70, 100% as 100, etc. Aside from the need to remember to * 0.01 on retrieved values and * 100 before persisting values, it doesn’t seem to be a problem in and of itself. It does make my head explode though… so is there a good reason for it that I’m missing? Are there compelling reasons to fix it, given that there is a fair amount of code written to work with the pseudo-percentages?

There are a few cases where greater than 100% occurs, but I don’t see why the value wouldn’t just be stored as 1.05, for example, in those cases.

EDIT: Head feeling better, and slightly smarter. Thanks for all the insights.

Answer 1

There are actually four good reasons I can think of that you might want to store—and calculate with—whole-number percentage values rather than floating-point equivalents:

1. Depending on the data types chosen, the integer value may take up less space.
2. Depending on the data type, the floating-point value may lose precision (remember that not all languages have a data type equivalent to SQL Server’s decimal type).
3. If the value will be input from or output to the user very frequently, it may be more convenient to keep it in a more user-friendly format (decision between convert when you display and convert when you calculate … but see the next point).

4. If the principle values are also integers, then

   principle * integerPercentage / 100 

   which uses all integer arithmetic is usually faster than its floating-point equivalent (likely significantly faster in the case of a floating-point type equivalent to T-SQL’s decimal type).