Why should zipcode values not be placed in Boyce Codd Normal Form?

Question

Can someone explain to me why it is that zipcodes should not be placed in Boyce Codd Normal Form? Is there really any more to it other than that zipcodes are unlikely to change in any foreseeable point in time?

Answer 1

Assuming you are talking about 2NF, not the minor difference between 3NF and BCNF, (cause zipcodes don't seem to be relevant to BCNF), then:
Yes, that, and the fact that it is unnecessarily obtuse, saves only one byte of storage, (zipcodes are five chars and can be stored in 5 bytes, an integer Foreign Key is 4 bytes), and requires an additional join to retrieve the value.

Answer 2

You should only place zip codes in 3NF or BCNF if your intention is to lookup other information based on them (such as locale). In that context, a zip code becomes a "natural key."

Absent that context, there doesn't seem to be much point. In most applications, a zip code is merely treated as a bit of text, and doesn't have any contextual meaning otherwise.

Answer 3

Zipcode is an attribute whereas BCNF is a property satisfied by a relation or set of relations. As a general rule, aim to be in at least BCNF unless and until you have a good reason to deviate from that. On that basis I'd suggest that relations with a zipcode attribute ought to be in BCNF. What makes you think otherwise?