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

On 27 mai, 14:58, "David Cressey" <cresse..._at_verizon.net> wrote:
> "Matthias Klaey" <m..._at_hotmail.com> wrote in message
>
> news:5bsi53h8bt88nf7iaj0tpk6e3rbjkv9mh8_at_4ax.com...
>
>
>
> > 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.
>
> > 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.
>
> I differ with the wording above. Here's an alternate wording: if you have
> a relation, the tuples will be distinct, by definition. This means that the
> entire tuple is either a candidate key or a super key. To discover
> candidate keys, one merely needs to discover the constraints placed on the
> data.
>
>
>
> > 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.
>
> OK, so theory never talks about this, but I will: data analysis.
Huh..But I thought that theory estalished predicates and true propositions. How do you establish a proposition with such taxonomy defined?

> > 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):
Mmmm..I wander if confusing taxonomy is also a science...

> I think this is a useful thinig to do, in the context that Joe originally
> did it in.
> Design practices, both best practices and others, sometimes elucidate
> theory, sometimes not.
> It's only when theory and alleged best practices contrdict each other that
> further investigation is necessary. (remember, "Theory IS practical")
Hey I thought we were talking about external vs internal data/ reality. Damn, now you bring theory vs practice...(I will never understand, I will never understand...)

;)
[Snipped] Received on Sun May 27 2007 - 16:41:41 CEST