>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 :)