Integer vs String in database

Question

When defining datatypes in a database, I have always had a problem with choosing whether to use integers or strings to store certain \'numerical\' data.

Say I am bui

Answer 1

in my opinion for postal codes you have to use strings, because you can have postal codes that stards with zeros (09100) and if you use integers it would be 9100: sorting is not a problem, because there is still an alphabetical order ('09100' comes before '09101'). For Storing file numbers I would expect an interger, so you don't have any problem in incresing / decreasing its number. So integer vs strings depends upon the use you make!

Answer 2

I don't use a numerical data type unless I expect to do math on the data. Why risk finding a problem in the future for something that you were "sure" would always be a number that someone decides to put a non-numeric character in.

If you aren't going to do math on it make it a string.

Answer 3

Well as far as postcodes go, this is a typical UK postcode:

EC2R 6PK

In university my databases lecturer told me something that has stuck with me and still holds 15+ years later:

If you perform arithmetic on it, store it as a number. Otherwise it's a string.

Frankly I don't think you can go wrong with that advice.

Obviously you don't perform arithmetic on postcodes, therefore they're strings.

Answer 4

It is also good to remember that not all postal codes in all counrties are numbers only. Just because you don't have any addreses in Canada right now doesn't mean you won't have any. I've always gone by the rule, if you want to do math calculations store it in a numeric type, if it is just a code (postalcodes, phones, SSN, partnumber, etc) then I store it as a string. What you want to avoid is any unnecessary casting of the data into another format every time you call it up (for instance code to add the leading zeros if you store the postal code as a number or code to convert a string to a number for calulations). These can be expensive operations if you need to do them repeatedly, espcially when the tables are large and you end up having to do the conversion in the where clause. It is far better to store the data the way you need to use it.

Answer 5

Somtimes "always" means "for the next month". I wouldn't count on 4 digit codes not going alphanumeric within the lifespan of my responsibility.

Some dialects of SQL support a dataype that's like NUMBER(4). This works much like a character string, but the alphabet is 0 through 9.

Answer 6

It is always important to understand the semantics of data you are working with. Let me explain it on the example.

Consider you want to store PIN in your database. To answer what datatype you should use you must firt answer what PIN (Personal identification number) really means.

1. If it is really a number as its name truly indicates then I don't see any reason why it shouldn't be represented as an integer.

   Some people could argue that you cannot distinguish between 0001 and 01. Evidently they do not consider PIN a number and if they are working witch such semantics they should use string.

   Note: If PIN length would be fixed to let's say 4 digits they could still use integer because any number will be always filled with leading zeros and will ment exactly the same (0001 will be the same as 01) - but these fixed length restriction are typical for numbers to avoid incorrect input.

2. If semantics clearly states that PIN is a number, i.e., that PIN 0001 is exactly same as PIN 01, I would use an integer representation.

Therefore in your case it is important to understand postal code semantics. That semantics can vary in different countries (or even change over time) so it is also important which do you want to use. To cover all sort of postal codes and even possible changes I would consider using more abstract data type or just a string (I believe there are already semantics that contains more characters than just digits).

I would not recommend to follow simplificated rules such as the one about arithmetric operations over data representation. If you do not want to perform mathematical operations with data now doesn't mean you will not want sometimes in future.

You have data and you want to store it, represent it somehow - simply think about what it is that you are working with.