Re: A question for Mr. Celko

"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:pan.2004.07.17.10.58.17.83649_at_REMOVETHIS.pandora.be...
>
> One criticism I heard is that to simulate the PACK and UNPACK operators
> you have to use operators that violate 1NF as it is usually understood.
> But note that the exact definition of 1NF is not as well-understood as one
> might suppose. Chris Date, for example, apparently has decided to
> trivialize the notion.

Is there any reason it shouldn't be trivialized? 1NF doesn't seem to do anything but get in the way of things like relation-valued or list-valued attributes.

If I have 2 tables:

foo { a:int, b:int } // a is primary key bar { a:int, c:int } // a references foo(a)

then this is exactly the same as having a relation of type:

foo { a:int, b:int, { c:int } } // a is primary key; c is set of int

So what, besides 1NF, prevents me from using the second, more convenient form?

> A calculus/logic-based approach would probably have been
> more appropriate here.

My suspicion is that the calculus-based approach won't play in Peoria, but maybe that doesn't matter to everyone.

> > This is quite different from Rick Snodgrass's approach, which requires
> > such Information Principle violating notions as hidden columns.
>
> If those hidden columns can be made visible I don't see why this would be
> such a big problem.

I'm not familiar with Rick Snodgrass's work, but I'm suspicous of hidden columns. Although, if they can be made visible, in what sense are they hidden?

> After all, the "information principle" is not some
> religious dogma but just a well-established well-tested and
> well-argued engineering principle.

Couldn't we say the same about 1NF? (Except for the "well-argued" part. :-)

Marshall Received on Sat Jul 17 2004 - 17:37:00 CEST