percentage values storage and retrieval

I am told that percentages should be stored in a raw format like 0.12 and
displayed as 12.00% on the front end. That means, I should multiply by 100
when I am pulling the data from the table and divide by 100 when I am storin
g
the data in the table.
This does not make sense to me. How about I store the data as 12.00 to begin
with in the table? And just pull it as it is in the table and do proper
processing when the values gets stored in the table right in the beginning.
Does that make sense?
Since this is a very simple issue, I thought I did not need to post sample
table and data.
Please let me know.
TIA...To me, it makes better sense to store the percentage value as a number less
than one (e.g., 0.12). In addition to just representing a percentage (12%),
you could use the percentage to calculate a discount for a price or other
operation. For that use,
it's better to keep the percentage like 0.12 :
--pecentage like 0.12
discount = price x percentage
--percentage like 12
dicount = price x percentage / 100 --harder to keep track of, IMHO
"sqlster" wrote:

> I am told that percentages should be stored in a raw format like 0.12 and
> displayed as 12.00% on the front end. That means, I should multiply by 100
> when I am pulling the data from the table and divide by 100 when I am stor
ing
> the data in the table.
> This does not make sense to me. How about I store the data as 12.00 to beg
in
> with in the table? And just pull it as it is in the table and do proper
> processing when the values gets stored in the table right in the beginning
.
> Does that make sense?
> Since this is a very simple issue, I thought I did not need to post sample
> table and data.
> Please let me know.
> TIA...
>|||Percentages are decimals, and are used as decimals. The data should be
stored in a format according to what it means and how it is used, not how it
is displayed. As a rule, databases are built around the data you work with,
applications are built around how you display that data. These rules should
only be broken as a last resort, and wanting an easier way to display a
value does not qualify.
Yes, storing it as an integer rather than the actual decimal value may save
you some keystrokes now, but it will result in calculation errors later on,
and will be a nightmare for the next person who has to manage the code.
"sqlster" <nospam@.nospam.com> wrote in message
news:B40FDAC5-D090-4F0D-ACE7-FCA12CB50570@.microsoft.com...
> I am told that percentages should be stored in a raw format like 0.12 and
> displayed as 12.00% on the front end. That means, I should multiply by 100
> when I am pulling the data from the table and divide by 100 when I am
storing
> the data in the table.
> This does not make sense to me. How about I store the data as 12.00 to
begin
> with in the table? And just pull it as it is in the table and do proper
> processing when the values gets stored in the table right in the
beginning.
> Does that make sense?
> Since this is a very simple issue, I thought I did not need to post sample
> table and data.
> Please let me know.
> TIA...
>|||A percentage is a value derived from a numerator and denominator, and if the
x and y are contained in the table, then there is no reason to add the
additional percentage column. If you have only the percentage, then you are
potentially losing information, becuase the question may be asked later how
the value was derived. Therefore, the best method of storing a percentage
may be perhaps:
x smallint,
y smallint
"sqlster" <nospam@.nospam.com> wrote in message
news:B40FDAC5-D090-4F0D-ACE7-FCA12CB50570@.microsoft.com...
>I am told that percentages should be stored in a raw format like 0.12 and
> displayed as 12.00% on the front end. That means, I should multiply by 100
> when I am pulling the data from the table and divide by 100 when I am
> storing
> the data in the table.
> This does not make sense to me. How about I store the data as 12.00 to
> begin
> with in the table? And just pull it as it is in the table and do proper
> processing when the values gets stored in the table right in the
> beginning.
> Does that make sense?
> Since this is a very simple issue, I thought I did not need to post sample
> table and data.
> Please let me know.
> TIA...
>