Re: Surrogate Keys: an Implementation Issue

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:nePyg.28677$pu3.392953_at_ursa-nb00s0.nbnet.nb.ca...
> paul c wrote:
>> Brian Selzer wrote:
>>
>>> What's the point of a database if it doesn't reflect some aspect of
>>> reality. Assertions are worthless without a frame of reference. A
>>> database can only guarantee consistency, not correctness. Therefore,
>>> the truth of a statement comes from without the database, that is, from
>>> reality. With surrogates, I can extract more meaning from a database by
>>> being able to determine which premises changed and how.
>
> A hidden surrogate does not allow you to do anything you cannot already
> do. If one needs to know the state of the database at some point of time
> in the past, one needs a database that does not discard log files and that
> can answer queries as of any point of time in the past.
>
> Whether entity A was at some physical location now occupied by entity B is
> uninteresting.
>

What do physical locations have to do with surrogates? It is interesting to be able to determine not only that a statement that was known to be true no longer is, but also what changed in the circumstances underlying that statement to negate that truth.

>
> I
>>> can also to avoid the problems that I described earlier.
>
> Bullshit. He keeps asserting this nonsense but he doesn't even understand
> the concept of a candidate key or that it first and foremost must provide
> logical identity.
>

I understand fully the concept of a candidate key; it is you who fail to understand it. A candidate key does indeed provide logical identity: the value of the key determines the values for the rest of the attributes, effectively identifying a tuple, but only within a single database state. It appears that you believe that the identity provided by such a value spans multiple database states. This is not always true. Consider an employee relation that has several unique attributes: (1) Social Security Number, (2) Employee Number, and (3) Badge Number. All are candidate keys because it is required that each be unique. All provide logical identity. Now, when an employee loses his security badge, he is assigned a new Badge Number. The Social Security Number is the same, as is the Employee Number, but the fact remains that a candidate key value is no longer the same in two successive database states. By your reasoning, this means that the employee no longer exists or is no longer relevant to the discussion. This is obviously not true, which begs the question: if the value of a candidate key for an entity that has multiple candidate keys can be different in successive database states, then why can't it for an entity with a single candidate key?

> [Selzer's infantile and malicious comments snipped]
Received on Sun Jul 30 2006 - 05:30:41 CEST