>>>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.
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only