If you use primary keys in addition to the other -user-defined?- unique value, then you can be sure that your records will always have a primary key. You don't need to worry about problems if the users don't fill in the unique value, or if they modify it, or if they...you get the idea.

Also, when users change the unique value in a table then you need to go to the children tables and update them to point to the new unique value. Since, most of the times, primary keys does not change (because the users does not even seem them) then you don't need to worry about this.

Also, with the use of primary keys you don't need to worry if the business rules change in the future and then the user-defined unique value is not required anymore. With the use of primary keys you know for sure that you will always have a unique value generated by the system regardless of the business rules and/or the users.

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