When designing geodatabases I have followed industry standards and used text and numeric fields. Some people have different ways of designing geodatabases and only use text fields. What are the schools of thought on text vs. numeric fields? Why would you use a text field when it is always a numeric value?
2 Answers
Among the other reasons given in the answer at the question I flagged this as a duplicate of, and to specifically answer your question of why text when it is a numeric value:
Just because it's numbers doesn't mean it's a numeric value. You do not add or subtract zip codes, phone numbers, serial numbers, etc. Both the storage of the value (leading zeros for instance) and the functions available (extracting or replacing characters for instance) depend on the data type selected. As mentioned at the other answer, generally if it doesn't represent a quantitative value, you won't perform math on it, or other potential special cases like Booleans, it should probably be a text field and not a numeric one.
Fundamentally I support Chris's answer. There's a few more points I would add and it's too long for a comment.
Mathematical operations (field calculations) are more convienient on an numeric field but can be achieved using operators like int()
on a text field. Sometimes fields that are almost exclusively numeric need to support strings like 44A, N/A, void.. these would need to go into a text field.
Where numbers come into their own is in less than or greater than logical operators. I can't think of any instance for Zip_Code < Value
or Phone_number > Value
that would seem logical, I can think of Phone_number like "0414*"
which is a text operator.
Boolean values (yes/no, true/false) could be text or a coded domain on a short integer which saves some database storage but an extract of the data would still only contain the 0 and 1. If you need to export/extract the data at any stage it may be better to store the textural values - space is cheap, time is expensive!
When designing a database a great deal of thought has to be put into the geometries, fields, domains (spatial and attribute) and subtypes. You need to think about how the fields are going to be used in the future and what kind of searching and calculations the fields are going to be involved in.
In my experience where a text field is used to store a number it will unavoidably collect non-numeric values. Even in the most validated and well maintained data there will be a leading space, trailing space or other text present. If you are going to use a text field to store a numeric value consider making it domain fixed.