Re: Pizza Example
Date: Wed, 07 Apr 2004 15:22:24 GMT
"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message
> <snip> > You now have the equivalent of a Pick RECORD (a bit like your
> > > row). We don't duplicate a simple attribute because it doesn't make
> > > sense to do so
> > In what sense does the relational model duplicate an attribute?
> > > why list it repeatedly when it only exists once per object?
> > There are multiple values which may be associated with X, but in what
> > is it "listed repeatedly"? Again, I don't see the "duplication."
> I suspect that Anthony was thinking of the output of a SQL SELECT
> He might not realize that the property of closure is not extended to
> in the relational model.
Actually it is - SQL falls short in some ways, but you can (often) at least do a SELECT from the results of another SELECT, at least within the confines of a single (nested) query. Maybe I'm not exactly addressing your point, though.
> That's my guess as to the gap on this one.
> With a relational database, a query might result in
> Jon Doe Pizza
> Jon Doe Garlic Bread
> rather than
> Jon Doe Pizza
> Garlic Bread
> When MV folks (PICK) look at SQL output, we shudder.
Many points here:
1. There's a big difference between query results and query output. I think this is where XML and other technologies get it wrong. 2. The result of a SQL select, due to poor language bindings, can't be further subject to SQL operations, unless you're within a query. So I can't do 2 selects, and take the results and joint them, and store the result in a variable. I can do that type of thing in a single nested query. This is another case of programming languages not being relational enough. 3. As another example, XQuery, may have some accidental incidences of closure, but is primarily a reporting tool, in that its output is text and needn't be valid XML or anything else in particular.
It's very important that the boundaries between "closure types" be kept sacrosanct, or your operations' typing will get watered down. Certainly there's a transition point (e.g. generating a PDF or HTML or XML from a query result), but you have to be clear about when you're in data-land and when you're in output-land.
Is it possible in Pick to do a LIST of some sort that is then not capable of having another LIST applied to it? It's altogether possible that Pick does a better job than SQL and its horrendous language bindings.
> Date's use of GROUP BY
> and UNGROUP as relational operators (IIRC) helps with this. But SQL does
> not take tables/views and output the same -- no closure there as we
> folks) are accustomed to.
Over what other operations are Pick data structures closed? Or rather, what Pick operations are closed over its data structures?