Re: A simple notation, again

"paul c" <toledobythesea_at_oohay.ac> wrote in message
news:BXRni.131566$1i1.60182_at_pd7urf3no...
> David Cressey wrote:> ...> > I'm with you on this right up to the point where you say you think that
this
> > is a fairly minor point of Codd's.> >> > List processing systems were quite well developed in 1970, both in
terms of
> > processing, and in terms of storage and retrieval. The Pick system
that
> > sometimes gets touted in here is basically a list processing system.
List
> > processing systems are fundamentally different from systems based on the> > relational model precisely because the list (1, 2) is not recognized as> > equal to the list (2, 1). Whether this is a convenience to the> > user-programmers, or represents an additional burden on them, in terms
of
> > the semantics of the data, is a very major point, indeed.> >> > The above says, somewhat more formally, what I was driving at a few
years
> > back, when I asked whether a pizza with onions and pepperoni was or was
not
> > the same thing as a pizza with pepperoni and onions. Unfortunately most
of
> > the discussion ignored the point behind the question.>> I should've tried to distinguish between manipulation and presentation.> I would certainly call it a "burden" if ordering were inflicted on me> when I had no app requirement for it.>> I live in the pizza boondocks so I've no doubt that here there is> definitely a requirement here for knowing whether onions or pepperoni go> on first, but not from me. But it hardly makes a difference with all> the dough they use here and it is virtually impossible to get any fresh> thin-crust pizza. But this is one of those provincial places where if> mustard is to be had at all, they're likely to put it on top of the> relish whereas everybody knows it must go next to the meat, if there is> any of that in the hotdog. I wish you'd change your example to mustard> and relish as talk of pizza makes me too angry to think!>

On a somewhat more mundane level, a question might arise as to whether an
"ORDER BY" clause should be forbidden in a CREATE VIEW. Going back to 1994,

DEC Rdb/VMS had no such prohibition. Turns out to have been a useful way to
standardize queries, including the order of presentation. You could even
then turn around and use such a view as if it were a table in other queries,
in ways that ran contrary to presence of the "ORDER BY". No problem, it
gave the right answers. I don't know whether the otimizer ended up doing an
unnecessary sort or not, but I didn't care much at the time.

Oracle RDBMS, on the other hand, did have such a prohibition. In Oracle, a
SELECT with an ORDER BY generated a "Cursor" (or some such thing as that)
while a SELECT without an ORDER BY generated a result table. So they
prohibited "ORDER BY" in a view. There was a situation where such a thing
would have been useful to me, but Oracle's punctiliousness prevented me from
having it my way.