>>>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.
>
>Sorry. If you would have need to modify or add additional choices to a combobox, then put the choices in a lookup table instead of a hard-coded array or hand-entered choices. The original question was when should a lookup table be used versus hand-entered choices (hard-coded). I strongly believe lookup tables should have a primary key (integer) field and a description field with the pk being the stored value in the data tables NOT the description -- descriptions can change causing a big mess in your data tables.

The original question was when should the lookup table have a separate key field, and you answered, in effect, "always". I guess that, even if the lookup table doesn't get modified often, you don't trust RI at all. But I suppose that there really is no reason not to use the key field, even if the descriptions are only three characters long.