Re: Pizza Example

Jan Hidders <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:<l5ifc.71570$MG1.4809827_at_phobos.telenet-ops.be>...
> Eric Kaun wrote:
> > "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
> > news:KVZec.70676$MG1.4809827_at_phobos.telenet-ops.be...
> >>
> >>So, one would expect that the NEST and UNNEST operators of the nested
> >>relational algebra would not be allowed, wouldn't one?
> >
> > Do you mean GROUP? As far as I know, those are merely shorthand, not
> > something new.
>
> ?? Are you saying that the GROUP / UNGROUP operators, as Date calls
> them, can be expressed with the operators of the flat relational algebra?

I believe these types of operators wouldn't conform to the rules of constructing well-formed formulas as well, which of course impacts FOL-based queries. In predicate calculus, the construction of a wff using a form G(P(x),...) is not allowed. I haven't had a chance to think much in terms of what the implications would be exactly however.  Perhaps you know.

• Dan

>
> >>I know I would.
> >>What else could "logically expose" mean for a relation-valued column?
> >
> > Operators on an attribute/column of type T are exposed, same as operators on
> > any other type are exposed for use on values of that type. But one could
> > certainly argue that the "nesting" in values/subvalues in Pick are simply
> > exposed operators of a 2/3 level type. Hmmm. Mayhap I've argued myself into
> > a corner. Or maybe it's just late.
>
> Maybe. Maybe it's just Date. :-)
>
> >>Ah, well, let me say here and now that I'm not a big fan of Chris Date,
> >>to put it mildly, and the arrogance of dbdebunk makes me physically
> >>sick.
> >
> > I can certainly see that, and I don't claim to be an expert - from what
> > you've written, I'm fairly sure you're much more knowledgable than I on
> > relational matters. But I find their site interesting, and useful as a
> > bulwark against the wave of "novel" new data management techniques. While
> > I'm not familiar with the "deep" research, I don't see much understanding of
> > relational in common practice, and think it's certainly better than the ad
> > hoc approaches being advocated.
>
> I agree with all of the above, although I would add that the "is
> certainly better than" should be qualified. An RDBMS is not *always*
> under all circumstances certainly better. As much as I dislike dbdebunk
> and Date's tendency to speak to us ex-cathedra of all things relational,
> I consider myself very much in the "relational camp" and believe it has
> the best (scientific and non-scientific) arguments of them all. That's
> exactly why we don't need all this religious zealotry with the
> apparently necessary condescending attitude and oversimplifications.
>
> -- Jan Hidders
Received on Thu Apr 15 2004 - 05:14:33 CEST