Surrogate Keys: an Implementation Issue

I'm working on a little RDBMs project, and I've been pondering the
general arguments for and against surrogate keys, and have come to
following conclusion:

The primary key should indeed be a natural key, if one is available, at
the model level, but at the implementation level the table should have
a system-supplied, auto-incremented, and hidden, "super primary
key". This super primary key, (SPK) is then used when populating FKs
in other tables (again, hidden from the user). It is up to the DBMS to
do the necessary conversions to insulate the user from knowledge of the
SPK.

If there is no natural key, then the SPK can simply be exposed to the
user as the PK for that table.

Thus, from the user's perspective, it appears that, say, Social
Security Number is sprinkled across a dozen different tables, when
under the covers its just meaningless 32 bit ints, and the SS number is
only stored once in the Employee table.

This seems to give all of the advantages of surrogate keys, (very easy
to change, saves on space) and the advantages of natural keys
(meaningful, etc), and conversely, none of the drawbacks of either. In
other words, the best of both worlds.

Is this a bad conclusion?

Do any current commercial RDBMSs already work this way under the
covers?

.

Relevant Pages

  • Re: Surrogate Keys: an Implementation Issue
    ... The primary key should indeed be a natural key, if one is available, at ... This super primary key, (SPK) is then used when populating FKs ... This seems to give all of the advantages of surrogate keys, ...
    (comp.databases.theory)
  • Re: Surrogate Keys: an Implementation Issue
    ... The primary key should indeed be a natural key, if one is available, at ... This super primary key, (SPK) is then used when populating FKs ... This seems to give all of the advantages of surrogate keys, ...
    (comp.databases.theory)
  • Re: Surrogate Keys: an Implementation Issue
    ... The primary key should indeed be a natural key, if one is available, at ... This super primary key, (SPK) is then used when populating FKs ... This seems to give all of the advantages of surrogate keys, ...
    (comp.databases.theory)
  • Re: candidate keys in abstract parent relations
    ... relational model has no problem a priori with surrogate keys, ... A common rule within the database design community is to abjure ... constraint to enforce) at least one natural key for each table. ...
    (comp.databases.theory)
  • Re: Surrogate Keys: an Implementation Issue
    ... Paul Mansour wrote: ... The primary key should indeed be a natural key, if one is available, at ... This super primary key, is then used when populating FKs ... This seems to give all of the advantages of surrogate keys, ...
    (comp.databases.theory)