Hi Steve,
Here is my take: If it is a number, as in a real number and not
something called a number that may not be a number, then store it as a number
because that will ensure that the data is always numeric. Just because you
are not doing calculations, does not mean that it is not a number. If there
is one thing I hate, it is getting data from sources in Access tables where
they store the numbers in text fields. That makes me check all those values
to make sure they really are numbers.
Explanation on "something called a number that may not be a number":
Telephone "numbers" as they often have extra characters--think especially
international numbers that do not follow your country's format;
company-internal numbers such as 2-3456; and cell-phone shortcuts such as
*123. I like to provide free-form text columns/boxes for those so the user
can enter whatever is necessary. National ID numbers which may use varying
formats and even letters.
If you set up for text columns for true numbers, it makes for a lot
more work to ensure that you only have true numbers in those columns. And
you have to enforce that everywhere that the data may come into your table.
In my opinion this issue far outweighs any minor performance hit in
formatting numbers to include leading zeroes or other types of formats.
Formatting of numbers is a well developed process that I am sure is designed
to be highly efficient. Reading data from disk and over the network is
likely to be slow in comparison to the execution of the formatting code. An
integer is two bytes. To store that same number as a text column you need up
to six bytes (one for the sign and five for the digits). For a long you need
four bytes as a number. To store that in text you need up to eleven bytes.
So storing those as text to can triple the amount of data you have to store,
send and retrieve. In a small database this will not be noticable. In a
large one it will.
Again, my take,
Clifford Bass