Return to Question

From first glance, it would appear I have two basic choices for storing ZIP codes in a database table:

1. Text (probably most common), i.e. char(5) or possibly varchar(9) to support +4 extension
2. Numeric (technically more efficient size-wise), i.e. 32-bit integer

Both would satisfy the requirements of the data. In the past we've generally just gone the text route, but I was wondering if anyone does the opposite? Just from brief comparison it looks like the integer method has two clear advantages. It is, by means of its nature, automatically limited to numerics only (whereas without validation the text style could store letters and such which are not, to my knowledge, ever valid in a ZIP code). Additionally, it takes less space, being 4 bytes (which should be plenty even for 9-digit ZIP codes) instead of 5 or 9 bytes.

Also, it seems like it wouldn't hurt display output much, as it is trivial to slap a ToString() on a numeric value, even using simply string manipulation to insert a hyphen or space or whatever for the +4 extension, so I don't think there'd be any hurdles when actually using it in a web application setting.

Is there anything I'm missing that would discourage using int as a datatype for ZIP codes?

UPDATE: Yes, this will only ever be used for US-based postal codes. 95% of them will probably all be ZIP codes from the same state, even. As for leading zeroes, couldn't you just do a ToString with a format string to add leading zeroes? I.e.: .ToString("00000")

From first glance, it would appear I have two basic choices for storing ZIP codes in a database table:

1. Text (probably most common), i.e. char(5) or varchar(9) to support +4 extension
2. Numeric, i.e. 32-bit integer

Both would satisfy the requirements of the data, if we assume that there are no international concerns. In the past we've generally just gone the text route, but I was wondering if anyone does the opposite? Just from brief comparison it looks like the integer method has two clear advantages:

• It is, by means of its nature, automatically limited to numerics only (whereas without validation the text style could store letters and such which are not, to my knowledge, ever valid in a ZIP code). This doesn't mean we could/would/should forgo validating user input as normal, though!
• It takes less space, being 4 bytes (which should be plenty even for 9-digit ZIP codes) instead of 5 or 9 bytes.

Also, it seems like it wouldn't hurt display output much. It is trivial to slap a ToString() on a numeric value, use simple string manipulation to insert a hyphen or space or whatever for the +4 extension, and use string formatting to restore leading zeroes.

Is there anything that would discourage using int as a datatype for US-only ZIP codes?