From first glance, it would appear I have two basic choices for storing ZIP codes in a database table:
char(5)
or varchar(9)
to support +4 extensionBoth 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:
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?
Zip codes are always 5 characters, hence you would need a CHAR datatype, rather than VARCHAR.
Well, ZIP codes are still not integers! ZIP codes for New England states all start with a "0." If your database stores its ZIP codes as integers, then those leading zeroes are stripped. That means a Boston ZIP code (02115) would incorrectly show up as a four-digit number (2115) instead.
Normally you would use a non-numerical datatype such as a varchar which would allow for more zip code types. If you are dead set on only allowing 5 digit [XXXXX] or 9 digit [XXXXX-XXXX] zip codes, you could then use a char(5) or char(10), but I would not recommend it.
You can use varchar column type for Zipcode in SQL Server. Varchar data type accept both numbers and characters.
A numeric ZIP code is -- in a small way -- misleading.
Numbers should mean something numeric. ZIP codes don't add or subtract or participate in any numeric operations. 12309 - 12345 does not compute the distance from downtown Schenectady to my neighborhood.
Granted, for ZIP codes, no one is confused. However, for other number-like fields, it can be confusing.
Since ZIP codes aren't numbers -- they just happen to be coded with a restricted alphabet -- I suggest avoiding a numeric field. The 1-byte saving isn't worth much. And I think that that meaning is more important than the byte.
Edit.
"As for leading zeroes..." is my point. Numbers don't have leading zeros. The presence of meaningful leading zeros on ZIP codes is yet another proof that they're not numeric.
Are you going to ever store non-US postal codes? Canada is 6 characters with some letters. I usually just use a 10 character field. Disk space is cheap, having to rework your data model is not.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With