>>>>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.
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