Re: Database design, Keys and some other things

From: x <>
Date: Fri, 30 Sep 2005 11:33:39 +0300
Message-ID: <dhit98$iot$>

"mAsterdam" <> wrote in message news:433cf1d0$0$11072$
> 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.
> A while ago we had some discussion as to wether an url is a key
> or not. My stance on that was: only if the content is in our
> database the url may be a key, so - in general: an url is not a key.
> There is a similar distinction to be made here.
> In general, a VIN is not a surrogate key (though it
> is in the "*some*" database - only there).

I think we need to use other word like identifier when talking about entities.
In the RM one can say the url is a key only if there exist a relation like At(url, content) in the database.
It doesn't make sense to talk about relational keys when we talk about entities.
We can talk how an entity is represented in a relational database. In general, an url is just a value. Received on Fri Sep 30 2005 - 10:33:39 CEST

Original text of this message