Re: A question for Mr. Celko

> 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.

I don't think Chris trivializes the notion at all, he clarifies the definition with the observation that type is orthogonal to the definition of a relation. All relations are therefore in 1NF by definition with no restriction on the types of values that can be contained in the tuples of the relation. I note also that even SQL:1999 would allow for the implementation of interval-valued types using structured types. It appears the SQL standard has adopted the same definition of 1NF, at least in spirit.

> Another criticism is that an algebraic approach is taken but one
> where the operators are not supposed to be implemented as such or where it
> would at least be impractical to do so. That deviates somewhat from the
> usual pattern. A calculus/logic-based approach would probably have been
> more appropriate here.

The proposals do not preclude a calculus-style language, it's just that the algebra presents the concepts more intuitively. I would also point out that most, if not all, implementations of calculus-style languages convert to an algebra prior to optimization, so there is no reason to believe that an algebraic implementation would be any less optimizable than a calculus-style one.

> > The domain of integers is infinite, but we are quite content to model it
> > with a finite set. In what way is this different?
>
> If you mean "implement it" by "model it" then, yes, you are right. But we
> are talking about a logical data model, not an implementation model, so
> why then not model it as the infinite set that it really is?

In the case of time, because the assumption dramatically simplifies the problem domain without sacrificing any power.

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

If they could be made visible (TSQL2 certainly does not propose to make them visible) then yes, I agree. But if they are made visible, why require a specific type of column? Much better to build the solution based on constructs already available in a relational language, as the Temporal book suggests.

In any case, this is not the only problem with the TSQL2 proposals. Another problem is the use of statement modifiers, which are not orthogonal, and are only useful in the simplest of scenarios. I don't know if you've seen the TSQL2 syntactic extensions, but if a proposal ever warranted the label "weird extensions", this is it.

Regards,
Bryn Received on Sun Jul 18 2004 - 04:30:10 CEST