Hi Walter,

Thank you for that tidbit. It is certainly another factor. It is also slightly more complicated when displaying related information on screens.
However, I am going to give it a go. Most of my systems do not need to handle huge quantities of data so it might be ok anyway.


>Don,
>
>>Your example of account numbers is perfect. In the old days, I would have only the account code and description in a file. Then if a user changed the account number to something else I would have to put in a routine which automatically updated all of the CHILD records with that changed code. Now, with primary keys, I can have a user change the account code and because that code was not stored with the child records (only the primary key was) I do not have to do anything. Perfect.
>
>Sad story to this structure is that for all kind of reports, views, etc, there is at least one extra join involved. Since joins are real performance killers, this method is not applied frequently in accounting systems, where tables tend to grow large and reporting queries can get complex. For performance reasons it is often better to stick with intelligent keys.
>
>Walter,
>
>
>>
>>
>>>Hi Don,
>>>
>>>OK, a little terminology check :-)
>>>
>>>If you require a key from one table into another table, then it's a foreign key for the first table, not a primary key.
>>>
>>>As to the unique code versus the primary key, there's nothing wrong with that as long as all "behind the scenes" referential integrity is done via the keys and you have some mechanism to ensure that the codes are unique. IAC, with an accounting system, you need to have these code. For example, a ledger account number will be a unique code but not necessarily a key. However, if at some point you change the account number in the chart of accounts, all transactions should remain booked to that account ... this will be accomplished if you are using the keys and not the unique code. See?
>>>
>>>
>>>>I am in the process of introducing the concept of primary keys to my data structures. I do not use databases at all. I will make use of a separate file to pull the keys from. My question is this ...
>>>>
>>>>When I build files containing things which require unique keys, such as something like EXPENSE CATEGORIES in an accounting system, I usually have a unique code associated with a description (i.e. AUTO - Automobile Expense, etc ...). This is so ingrained into my thinking that recently when I began using Primary Keys, I had a file in which I inserted both a Primary Key AND the unique code which is associated with the description.
>>>>
>>>>This seems redundant but before I take the leap and get rid of the unique code I would like some sort of supportive statements from this forum confirming that this is in fact the way to go or alerting me to some pitfalls to this path. Any comments ?