Re: Database design, Keys and some other things

From: JOG <jog_at_cs.nott.ac.uk>
Date: 30 Sep 2005 06:56:04 -0700
Message-ID: <1128088564.223978.235660_at_g43g2000cwa.googlegroups.com>


> Marshall Spight wrote:
> > JOG wrote:
> [snip]
>
> >>A VIN exists in the real world, and as such is part of the proposition
> >>we are encoding. A surrogate key is an artifice of the database, does
> >>not exist in the world you are modelling, and is implemented to get
> >>your system working. This seems a very clear distinction to me.
> >
> >
> > Perhaps we have different definitions of surrogate keys. The VIN
> > may be something that's not a surrogate key in database A, but
> > it's certainly a surrogate key in *some* database, and hence I
> > don't see any particular difference between it and any other
> > made-up identifiers. SOMEone, some database, made up the VIN
> > out of thin air; we could well say they "implemented [it] to get
> > [their] system working." So I still don't see the distinction
> > you're drawing here.
>
> There is an important difference. Unless we are talking about
> that specific "*some*" database, the VIN is /not/ a surrogate key in
> the database at hand.

I'd answer along the same lines as mAmsterdam. The difference is that a VIN is controlled externally to the database (owned by the real world as it were) and a pure surrogate key is controlled internally within the RDBMS (owned by the database). The distinction guarantees that the latter is immutable and unique, which is not the case with the former.

And of course, yes, as soon as these lines blur and the pure surrogate key (and by pure i mean solely db owned), starts to be used outside of the db, the real world has taken over ownership of it, and it loses all its guarantees. Received on Fri Sep 30 2005 - 15:56:04 CEST

Original text of this message