>>Hi guys!
>>
>>>>>>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.
>>>>
>>
>>Ed: Don't forget that one of the rules of normalization is knowing when to denormalize. If the description in the lookup table is static, go ahead and store it and not a primary key to it. If it's somewhat dynamic, use RI to ensure that changes are reflected whereever the changes are made. If it's really dynamic, then your method is required. I think Mark and I are thinking the same way here.
>>
>Yes, this is question about attitude. For example, I always develop app as multiuser even it's supposed to be standalone :)

I'm very wary of over-normalizing, especially with static lookup tables, because of the potential for overcomplexity in joins for reporting or OLAP-type operations. I've been burned before on it :)