Re: Little design mistakes that can be easily avoided (2): Listenning to CELKO (and CELKO alikes)

"Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx> wrote:


"Matthias Klaey" <mpky@xxxxxxxxxxx> wrote in message
news:5f2k53pq5srphk68s1op58udei9h60stuo@xxxxxxxxxx
"Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx> wrote:


"Matthias Klaey" <mpky@xxxxxxxxxxx> wrote in message
news:bipi53pjf51gluul6b3b8uv86kbq7hanse@xxxxxxxxxx
Cimode <cimode@xxxxxxxxxxx> wrote:


Matthias Klaey a écrit :
Cimode <cimode@xxxxxxxxxxx> wrote:

On 26 mai, 18:18, Matthias Klaey <m...@xxxxxxxxxxx> wrote:
Cimode <cim...@xxxxxxxxxxx> wrote:
Hi,

[...]

[...]



If you've studied it, they you know that Celko's failed to mention the
last
paragraph of section 4, which is in direct contradiction to his rant.
I've
pointed this and other things out to him before, but he still dumps the
same
flawed argument on people all the time. In other words, he *knowingly*
mischaracterizes Codd's position to advance his own agenda. (He wants
people to buy his books!)

[...]

Or this one? Paper 2, Section 4 last paragraph

"They will have to remember, however, that it is now the surrogate
that is the primary key and provides truly permanent identification
of each entity. The capability of making equi-joins on surrogates
implies that users see the headings of such columns but not the
specific values in those columns."

And how, specifically, does any of these paragraphs contradict Celkos
"rant" (sic!)? Does it contradict the whole of it, or just part of it,
and if the latter is the case, which part?


This is the one. It directly contradicts the following paragraph in Celko's
["rant" is a bit more polite than "spew" It certainly doesn't rise to the
level of an argument. The fallacies and deliberate attempt to mislead place
it more in the category of propaganda than anything else.]:

<<
This means that a surrogate ought to act like an index; created by the
user, managed by the system and NEVER seen by a user. That means
never used in queries, DRI or anything else that a user does.


Which sums up his entire argument against surrogates. He then uses the term
"authority" as if in the article Codd was arguing against surrogates, when
the section he quoted (or deliberately misquoted) is a clear argument in
favor of surrogates! Now, while I'm not sure I agree with Codd when it
comes to hiding surrogate key values, I certainly wouldn't twist his words
completely around in order to support my own agenda!

I don't think that Celko argues *against* surrogates, in sharp
contrast to "exposed physical locators". He clearly makes the
distinction between the two types.

The only issue I see is about the visibility of surrogate key
*headings* in equi-joins. The values have no meaning whatsoever to the
user, as s/he cannot use them in Inserts, Updates, or Deletes.

I do not understand why it should be neccessary to display the
headings of the surrogate keys in an equi-join. If I know that
relations R and S have surrogate (primary) keys, I should be able to
write a view

equi-join(R, S)

without even having to know the names of the primary keys.

Greetings
Matthias Kläy
--
www.kcc.ch
.

Relevant Pages

  • Re: Little design mistakes that can be easily avoided (2): Listenning to CELKO (and CELKO alikes)
    ... And how, specifically, does any of these paragraphs contradict Celkos ... This means that a surrogate ought to act like an index; ... *headings* in equi-joins. ... A surrogate key value does indeed have a meaning. ...
    (comp.databases.theory)
  • Re: Little design mistakes that can be easily avoided (2): Listenning to CELKO (and CELKO alikes)
    ... paragraph of section 4, which is in direct contradiction to his rant. ... And how, specifically, does any of these paragraphs contradict Celkos ... This means that a surrogate ought to act like an index; ... it still refers to the same object. ...
    (comp.databases.theory)
  • Re: Surrogate Key
    ... Surrogate key is an unfamiliar attribute, assigned to an entity for the sole ... The assignment can be done either by the user or ... Thus you can decide on your own whether using an additional identifier is ...
    (microsoft.public.sqlserver.programming)
  • Re: How to ID a record
    ... > or trying to alter a primary key later and all the other probabilities. ... In reality a surrogate key doesn't really identify a record except so far as ... "Ray" wrote in message ...
    (microsoft.public.access.tablesdbdesign)
  • Re: Negative Numbers in "Identity" or" Autonumber" fields
    ... I have run in to this construct a few times in the past, in papers ... In the RM world it can function as a surrogate. ... run into this is security papers. ... One argument for its use as a surrogate key is that ...
    (comp.databases.theory)