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 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?

Answer 1

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. Saving one byte isn’t worth much, and I think 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.