Re: A real world example

From: Brian Selzer <brian_at_selzer-software.com>
Date: Wed, 16 Aug 2006 17:16:57 GMT
Message-ID: <dqIEg.7613$%j7.1983_at_newssvr29.news.prodigy.net>


"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:IaHEg.48774$pu3.573875_at_ursa-nb00s0.nbnet.nb.ca...
> JOG wrote:
>
>> Just as it is good to describe a person by something that will remain
>> consistent (for example telling someone that they will recognise 'john'
>> by his 'green jumper' is not particularly useful if he does actually
>> change his clothes once in a while), so in database design it is vital
>> to pick a good candidate key. Desirable properties are:
>>
>> 1) very likely to maintain uniqueness over relation values.
>> 2) very unlikely to change between relation values.
>>
>> The RM does not require that anything is immutable, but clearly,
>> finding a key that tends to immutability is desirable for (2).
>>
>> It appears to me reading the posts in this thread, that everyone is
>> agreed on these points, so I would like to suitably bang all your heads
>> together, as in some instances you are all just agreeing loudly, just
>> with the vociferous bluster of miscommunication.
>
> I disagree with your analysis.
>
> A self-aggrandizing ignorant showed up and posted nonsense. In fact, he
> continues to post nonsense. However, he now has you trained to re-define
> your existing vocabulary to turn his nonsense into something not only
> sensible but wholly unremarkable.
>

I may be ignorant when it comes to terminology, but at least I know the definition of a candidate key and intimately understand its scope and limitations. Most of your arguments have been completely debunked because they're based upon a false premise. The rest of your bloviating concentrates only on denigrading anybody who doesn't share your views, even after having been given ample evidence to the contrary.

> Design criteria for choice of candidate keys include: familiarity,
> irreducibility, simplicity and stability.
>
> See http://www.dbdebunk.com/page/page/622344.htm
>
>
>> Given that all are agreed that surrogates are useful
>
> I disagree that the concept of surrogate vs. natural is useful. A natural
> key is merely a familiar surrogate. The self-aggrandizing ignorant now has
> you redefining terms to make "surrogate" synonymous with "stable" and to
> make "natural" synonymous with "unstable".
>
> 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?
>
>
> , this leaves the
>> _only_ point that seem to be in contention:
>>
>> "Should a surrogate be made hidden from the user"
>
> I disagree that the above is the only point that remains in contention,
> and I would further note that the issue does not remain in contention
> among any who are reasonably informed and intelligent.
>
> Familiarity is generally as important a design criterion as stability. In
> specific contexts, one or the other may have greater pragmatic
> repercussions. Hiding values not only precludes familiarity but violates
> the Information Principle with all that that implies.
>
>
>> I'd contend no, absolutely not. Surrogates are instigated by real world
>> difficulties in distinguishing items even if they are generated by a
>> DBMS (in fact it does not matter a jot what generates them logically).
>> Hence if they are hidden, it is a clear violation of the information
>> principle, which is vital for the real world identification that
>> precipitated the need for them in the first place.
>
> All identifiers--even in 'the real world'--are surrogates. Every last one
> of them. What then is the use of the term? Twenty years ago there was some
> discussion of surrogate keys vs. natural keys, but further reflection
> reveals that natural keys are nothing more or less than familiar
> surrogates.
>
> The term 'intelligent key' at least defines a proper subset of keys. The
> drawback of an intelligent key is increased instability. Sometimes,
> though, intelligent keys offer mnemonic or verification advantages related
> to familiarity. Whether to use an intelligent key then becomes a pragmatic
> tradeoff between stability and familiarity.
>
> There really is little more to discuss about natural keys vs. surrogates
> except that self-aggrandizing ignorants periodically appropriate the terms
> in the nonsense they spout. The more you try to make sense of the nonsense
> the more you legitimize the self-aggrandizing ignorants without any
> further benefit to anyone.
>
> If you are going to engage the self-aggrandizing ignorants, please, do
> better at calling them on their bullshit.
Received on Wed Aug 16 2006 - 19:16:57 CEST

Original text of this message