>>>>Suppose you have a lookup table with one character field. Selections from this table are entered in a related field in some other table. If the strings in the lookup table were really long, most of us would make a keyfield for the lookup table and store that key in the related table, instead of the long string. But many would not bother if the strings were only a few characters. For the sake of speed, where do you draw the line? Six characters? Twenty? Also, does the number of records in the lookup table make a difference?
>>>
>>>From normalized data standpoint you should have at least 2 fields in lookup table: ID (primary key) and Description.
>>
>>Would you make an ID field even if the Description had unique values and was, say, three characters long? My question is: where do you draw the line?
>>
>>Mark Mccasland says that frequency of lookup table modification affects this decision, but I'm not sure how.
>
>If you routinely have to modify a lookup table (slight changes to descriptions, add additional values, etc.), make it a lookup table. Don't tell me your users or customers are 100% thoughtful and precise (and not flaky) so when they tell you about data suitable for a lookup table that it won't change in the future (like within about 3 days after delivering the app).

I didn't understand the first sentence of that reply.