I am assuming here that the fields that will form the PK cannot be changed (similar to the surrogate key, they would be computer generated). What other problems are there related to using the combination of fields rather than a surrogate field.

Using my example of version/revision numbering - I have got to make sure that no duplicates exist or any revisions omitted - if I went from V1.00A to V1.00C the auditor would want to know where V1.00B was - so all of this has got to be coded. What benefit does a separate surrogate field give me ?

If you were going to allow for operator error in entering numbers, another question an auditor might ask is why record refered to by key #12345 refered to V1.00A of document X at one point and later refers to V2.34D of document Y, because you've allowed correction of the version/revision numbers. Either system seems to have inherent problems if you allow modification of the important fields.

>Paul,
>
>PMFJI, but you are trying to create a system that is meaningful to a person, not a computer. We had that discussion here, some were using a combination of fields which together were unique, but could be changed. When a portion of the primary key was changed, all related tables needed to be updated with the new foreign key. When we changed to surrogate keys, no additional processing was necessary.
>
>Just my $0.02
>
>Rex
>