You are correct: these are, indeed, “surrogate” keys.
“Constants aren’t. Variables don’t. Unique numbers aren’t (at least not if any human being has anything to do with it). Even computer-generated “non-repeating” numbers sometimes do. Plan accordingly.”
As a general design principle, I routinely elect to use surrogate keys as the record-identifiers, i.e. for table-JOIN purposes, and to use UNIQUE indexes for any of the “natural” uses that you describe.
I learned to do this when working on a very early project for an insurance company which had converted from an original paper-based provider-ID numbering system. The same provider-ID was assigned to more than one provider, and providers had more than one ID. Furthermore, business requirements made it impossible for this situation to be changed, because these numbers were widely-distributed in the field. My strategy involved the use of surrogate keys. These keys were “nonsensical character strings,” much like these, and they were never, ever divulged to the user. The application stored the provider-ID number that had been entered, which was known to be ambiguous, and it resolved that ambiguity (by various rules and by user-input) and stored the corresponding (unambiguous) surrogate-key in another column. All table linking took place using the surrogate columns. This approach did successfully solve what was up to that time a very thorny business problem.
|Replies are listed 'Best First'.|
Re^3: An improved technique for database primary keys
by herveus (Parson) on Nov 08, 2010 at 15:55 UTC