Re: A real world example
Date: Wed, 16 Aug 2006 19:55:51 GMT
Message-ID: <bLKEg.7744$%j7.7343_at_newssvr29.news.prodigy.net>
<anithsen_at_gmail.com> wrote in message news:1155755711.886115.75780_at_74g2000cwt.googlegroups.com...
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message > news:XkJEg.10231$o27.1677_at_newssvr21.news.prodigy.com...
>>
>> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
>> news:1155746467.961871.76490_at_b28g2000cwb.googlegroups.com...
>>> Bob Badour wrote:
>>>> [snip]
>>>> By accepting his misuse of vocabulary, you encourage and legitimize the
>>>> illegitimate while you interfere with communication and comprehension.
>>>> Is it your goal to understand theory or to market the services of
>>>> ignorants at the expense of their potential clients and other
>>>> stakeholders?
>>>
>>> Of course not. All corrections are welcomed Bob.
>>>
>>>> [snip]
>>>> I disagree that the concept of surrogate vs. natural is useful. A
>>>> natural key is merely a familiar surrogate.
>>>
>>> By this I am unclear what a natural key is a surrogate for. If you
>>> could spend some time expanding this definition, or referencing it, I'd
>>> appreciate it.
>>>
>>>> The self-aggrandizing
>>>> ignorant now has you redefining terms to make "surrogate" synonymous
>>>> with "stable" and to make "natural" synonymous with "unstable".
>>>
>>> Piffle, bob. I have not adopted any of his terminology in my effort to
>>> engage him, and you are misrepresenting my understanding of terms.
>>>
>>> I view a surrogate as a 'substitute' for an unrecordable distinguishing
>>> attribute or set of attributes. This is the only logical definition
>>> that I am currently happy with. It does not require stability by
>>> definition, and I have only ever stated that stability is an attractive
>>> quality and hence often appropriate to good design. That's my current
>>> standpoint, and so that is what should or should not be criticized.
>>>
>>> Nevertheless I do not think you understood where Brian's mistakes stem
>>> from, and that's what I have been looking for. It appears to be a
>>> fundamental difference in what he views _identity_ to be. If the OP
>>> does not maintain this basic concept of identity as we do (and as Codd
>>> and Liebniz did) then there is little point in debating natural or
>>> surrogate keys with him at all. The problem goes far deeper than that.
>>>
>>
>> This thread started out because I objected to Bodour's statement,
>> "natural
>> keys are just familiar surrogates."
> > All you had to do to prove him wrong was to provide an example of a > natural key that is not a familiar surrogate. >
>> That goes counter to the understanding
>> I've held for years, that is supported by both Codd and Date. Codd used
>> the
>> term "permanent" to describe surrogates. Date implied permanence also by
>> describing a surrogate's value as one that has never been used and will
>> never be reused. Therefore, when I think of a surrogate key, I think in
>> terms of permanence, not just stability.
> > Neither Codd nor Date suggested the "permanence" of surrogate values, > but the permanence of the surrogate key. >
I disagree. Codd emphasized the need for permanent identifiers for entities immediately before introducing the concept. I grant that he did cite drastic circumstances that may require them to change, such as merging databases.
>>
>> Do you agree that in one relation value a candidate key value can
>> identify a
>> tuple?
>>
>> Do you agree that a relation schema can have more than one candidate key?
>>
>> If only one candidate key value is different in successive relation
>> values,
>> can the others identify corresponding tuples in both relation values? I
>> guess more importantly, do you think that the tuples correspond?
>>
>> If tuples can correspond in successive relation values that have multiple
>> candidate keys where at least one remains constant, then why can't they
>> correspond in successive relation values where none remain constant?
>> What
>> is being identified by corresponding tuples in successive relation values
>> that have more than one candidate key where only one of the values have
>> changed? The tuple? No, I don't think so. I think that it is the thing
>> that the corresponding propositions are referring to.
>> This is the source of the confusion. This is the impetus of my argument.
>> If the thing that is indirectly identified by a candidate key can have
>> its
>> appearance altered without altering its identity (which must be possible
>> if
>> tuples that are different can correspond), then it is possible to have
>> tuples in successive relation values that should correspond but don't.
>> This
>> is why I'm arguing for some mechanism to guarantee the ability to
>> correlate
>> tuples.
> > So you are arguing for tuple identifiers rather than a candidate key. > Here is an old post that references the quote on the distinction: > http://groups.google.com/group/comp.databases.theory/msg/bab7d889d157f137 >
No. I'm arguing for a theoretical mechanism to correlate tuples during an update. If you can reliably correlate tuples without an immutable key, then it doesn't matter whether or not the only key changes, you can still be sure that your talking about the same thing during an update. My point is that regardless of the mechanism, whether that's surrogate keys, tuple identifiers, or a tuple-level assignment operator (Oracle has a FOR EACH ROW trigger, as do several other implementations, but I would argue for a non-procedural mechanism.), the model is incomplete without it. I think that surrogate keys make the most sense, since they are essentially properties of things in the universe of discourse, but an argument can be made for tuple identifiers as well, at least for temporal databases.
>>
>>> Jim.
>>>
>>
>>
>
Received on Wed Aug 16 2006 - 21:55:51 CEST