Makes sense to me.
Thanks.





>Hi don,
>
>>I was referring to not using codes at all. For example, suppose I had a file of expense categories with nothing except the description of the categories in it. Then when I entered the expenses ... I would select the category from that file and put the entire category description in the expenses file. That would mean that if someone wanted to change the description of the category then all of the category descriptions in the expenses file would have to be updated. Messy but seldom occurs.
>
>This is a strategy I use when I want to use a lookuptable for entering cities. In the personstable, the name of the city is a foreign key to the cities table. Since cities seldom change names, I can't find any objection agains it. Using a surrogate key here is way overdone.
>
>However when talking about using (short) codes in stead of full descriptions keep the following in mind: If in the real world codes are used in every days language (like policecodes) or for reporting it is wise to use this codes in your system. For example in a sales report its often better to use the state code ("WA", "NY", "CA" ...) than the full name of the state. The same applies to for example clients. A client has a number because its better identified than with "Tax Software, Hoogkarspel, The Netherlands". Codes are really usefull for reporting also, because they generally require less space than it's full description, and if the codes are known by the reader the report also is more readable.
>
>Walter,