Re: Number or character?

mstein_at_access.digex.net (Michael P. Stein) writes:

> [Question about employee table and having a STATE table with the employee
> STATE field being a foreign key, and what data type to make the foreign key]
>
> This is a classic example of too much of a good thing. Normalization
> is fine up to a point, but this is carrying it too far. There is a
> reasonable efficient natural coding: the two-character postal state code
> (NV, TX, etc.). If you really need to have 'Nevada', 'Texas', etc, then
> go ahead and have a state table keyed by this code. Trying to shrink
> this to a one-byte code is carrying things too far. Are you that hard up
> for disk space? Even a million employees would only add one meg of storage
> going with two bytes rather than one. Remember, *people* have to use
> your data; how do you expect them to know what state code '7' means?
The example I used was merely an example. The jist of the question can be summarized as:is there any performance tradeoff for making a foreign key (ex. a code pointing to the table that tells you what the code means) a number or a character?

---
sullivan_at_sytex.com (mike sullivan)
Access <=> Internet BBS, a public access internet site
Sytex Communications, Arlington VA, 1-703-528-4380