Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: A simple notation, again

Re: A simple notation, again

From: David Cressey <cressey73_at_verizon.net>
Date: Fri, 20 Jul 2007 04:47:01 GMT
Message-ID: <97Xni.12922$s25.7043@trndny04>

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

> p
Received on Thu Jul 19 2007 - 23:47:01 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US