Identifying by location -- Was: A pk is *both*...

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:r0eri.17043$fJ5.1008_at_pd7urf1no...
> Brian Selzer wrote:
> ...
> > Given a choice between a key that permanently identifies individuals and
a
> > key that contingently identifies individuals, which would you choose to
be
> > the primary key, and thus the target of all foreign keys? Don't you see
a
> > problem with a relation that represents the histories of a set of
> > individuals where those individuals are denoted only by a set of
attributes
> > that contingently identify them?
> > ...
>
> No, I don't imagine any particular problem. I'm darned if I'm going to
> get sucked into judging such shapeless questions in a vacuum, whether
> contingent vacuum or non-contingent vacuum, whatever contingent means
> here. If the word "contingent" ever has any place in a db topic, even
> though I doubt it does, it would be with reference to an application.
> Same goes for other loose lingo like "rigid".
>
> > But requiring that all key values permanently identify individuals
> > significantly limits the expressiveness of the model, cutting in half
the
> > expressions that can be used to denote individuals, thereby reducing the
> > number of queries that can be formulated. Referring to my previous
example,
> > a query such as "Which part has lot number 203 in location 22?" could
not be
> > considered deterministic if the key, {lot_number, location}, were not
> > defined, and thus should be rejected as being formulated incorrectly.
> > Without that key, there can be more than one part with lot number 203 in
> > location 22, and you can't stuff a relation value into a tuple variable.
> > ...
>
> I'm glad that isn't phrased as a question, because words would fail me
> if I tried to answer it! Maybe somebody else wants to try.
>
Paul C,

I'd like to try to reframe this discussion by changing the context from "The part with lot number 203 at location 22" to another item that is commonly identified by location. I'm thinking of web pages.

A hyperlink embedded in HTML text does not specify the identity of the page pointed to, but rather its location. Recall that the "L" in URL stands for "LOCATOR". It's possible to break a hyperlink simply by moving the target page. "Moving" can be construed as a two step process: creating a copy at a new location, and destroying the copy at the original location.

How many of us have experienced the frustration of following a link that we rely on, only to get the dreaded "Error 404" (Page not found). There are billions of broken hyperlinks out there. The question might arise whether it isn't irresponsible on the part of the one who moves a page not to put a jump page back at the original location. Aside from being extra work, this carries problems of its own.

In essence, when you use locators as if they were identifiers in a reference system, you're back to the graph model of data. A similar problem occurs when you try to move a record in one of the old network (e.g. CODASYL) databases. The existing references to the record require for their stbility that the targeted record be "pinned" to its current location.

 So, looking at it this way, the web is the largest graph there is. Pages may be pinned, and there is no way for the owner of a page to know that it is not pinned. Received on Mon Jul 30 2007 - 13:13:35 CEST