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

On 27 mai, 14:23, Matthias Klaey <m..._at_hotmail.com> wrote:
> Cimode <cim..._at_hotmail.com> wrote:
> >On 27 mai, 05:16, paul c <toledobythe..._at_oohay.ac> wrote:
> >> Matthias Klaey wrote:
> >> > Cimode <cim..._at_hotmail.com> wrote:
> >> > ...
>
> >> > Hmm. Is this just the usual Celko-bashing in this newsgroup? Did you
> >> > intend to write a parody on how to misread and misinterpert other
> >> > peoples texts? You don't mean this seriously, do you?
>
> >> Usually I think much of what he writes here deserves to be bashed as it
> >> is not about theory, just various flawed products, workarounds and
> >> various design gospel he likes to preach. I think it's okay to talk
> >> about that stuff in a product group but this is a theory group.
> >Agreed. When one wants to speak about *taxonomy of keys*, one ought
> >to bring specific and sound scientific logic argumentation.
> >Disseminating product information with wax of science is not the same
> >as science. It hurts both science and truth.
>
> Please, Cimode. In Celkos text on the taxonomy of keys there is *not a
> single* reference to a database product.
Google up *cookbook approach*.

> He does advertise his own work, but this doesn't bother me, just as
> Bob Badours permanent swearing doesn't bother me much either.
>
> As for the *content* of Celkos text and its relation(!) to database
> theory (short of copying large parts of a book on this theme, I am
> speaking colloquially here):
>
> 1. In the Relational Model, the key is part of the definition of a
> relation (= table in practice). You don't have a relation if it
> doesn't have a key.
Oh thanks. Never thought about that.

> 2. Theory never talks about *how* you obtain this key. It is just
> assumed that it exists. It talks about candidate keys, primary
> keys and other mathematical concepts that apply here.
Hey but I thought that there were 4 types of keys ?

> 3. Celko classifies the kinds of keys that are used in practice.
> Taxonomy is a science in its own right. His text is more of an
> expose, it could easily be expanded to twenty pages or so. But his
> conclusions nevertheless are valid and sound (a little bit expanded
> by me):
What degree of reliability could be granted to a taxonomy that you don't even recognize fully as sound theorically? Doesn't it seem awkward that conclusions in practice could be good when their theoriy ground is not?

> 1. First, look for a natural key. If necessary, normalize your
> tables, because if you don't find such a key, this is almost always
> a sign of badly designed tables.
> 2. If you don't find a natural key, construct your own artificial key.
How?

> 3. Never ever use "exposed physical locators" such as IDENTITY columns
Ah..It seems there should be avoided. So why talk about them? (and put them in a taxonomy?)

> 4. When you construct a dbms (and only then), you might want to
> investigate surrogate keys, mostly for performance reasons.
Hey that's something interesting.

> Greetings
> Matthias Kläy
> --www.kcc.ch
Received on Sun May 27 2007 - 16:34:42 CEST