Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Surrogate Keys: an Implementation Issue

Re: Surrogate Keys: an Implementation Issue

From: paul c <toledobythesea_at_oohay.ac>
Date: Sat, 29 Jul 2006 23:03:05 GMT
Message-ID: <JORyg.266970$iF6.52104@pd7tw2no>


Bob Badour wrote:
> paul c wrote:

>> Brian Selzer wrote:
>>
>>> ...

>
> A hidden surrogate does not allow you to do anything you cannot already
> do. ...

No disagreement about that, but another perhaps minor point which confuses me - CJ Date seems to discount a 'hidden surrogate' based on the information principle, ie., IIIGIR, a surrogate must be exposed, otherwise it's something physical. I've been discounting what I think Codd meant, a 'hidden key' that has some other properties to boot, which a dbms might offer verbs to create or manipulate. (I don't see how you can have verbs without saying what they are allowed to operate on.) My perhaps not-too-deep appreciation makes me think that I don't agree with them unless the dbms is a kind of superior application which is probably over my head as far as implementations go. After a couple of days of this, I still am not able to distinguish a surrogate that I can do anything with, from a candidate.

(I remember from years ago using and maybe seeing others use, the term 'surrogate locks' to stand for 'intention' locks that prevented concurrent programs from sharing the ability to assert certain values of tuple components, ie. standing for rows that were in the unstated complement of a relation. But if we chose to show extensions for complements, then the surrogates wouldn't be hidden! Maybe that is a connection with what is confusing me.)

p Received on Sat Jul 29 2006 - 18:03:05 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US