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: separation of church and state?

Re: separation of church and state?

From: Cimode <cimode_at_hotmail.com>
Date: Tue, 09 Oct 2007 01:46:55 -0700
Message-ID: <1191919615.718356.241330@d55g2000hsg.googlegroups.com>


On Oct 8, 3:24 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> David Cressey wrote:
> > "paul c" <toledobythe..._at_ooyah.ac> wrote in message
> >news:hoONi.6504$_K.2827_at_pd7urf3no...
>
> >>I finally sprung for CJ Date's "Writings, 2000-2006" and skimming it,
> >>noticed this point in chapter 10. It reminded me of the recent posts
> >>about avoiding books that start with silly sentences even though this
> >>quote is from page 174:
>
> >>"Ordering, by contrast, is not part of the relational algebra; nor can
> >>it be, because its result isn't a relation. This doesn't mean you can't
> >>have an ORDER BY operator, of course - it just means that operator isn't
> >>part of the algebra as such, and it can't be used in an expression
> >>that's nested inside some other (relational) expression, or more
> >>generally in any context where the result is indeed required to be a
> >>relation. That's why you can't use ORDER BY in a view definition, for
> >>example."
>
> >>It seems a little doctrinaire to me. I can agree that the "result isn't
> >>a relation" but on the other hand a user could see such a result without
> >>knowing that "ORDER BY" was involved and not be faulted for taking it to
> >>be a relation. For that matter, in some apps, users take it for granted
> >>that all results are arbitrarily ordered and that those results can be
> >>used to produce other results.
>
> > It is a little doctrinaire. Oracle/Rdb (originially DEC Rdb/VMS) has
> > always allowed ORDER BY in a view definition. No damage was done to the
> > ability of the user to apply concepts of relational algebra to the task of
> > getting useful work done. One could reference such a view inside another
> > view, or in any other context where an unordered table would have been
> > expected, and the results were logically equivalent to the result one would
> > have obtained in the absence of the ORDER BY.
>
> > Oracle RDBMS, by contrast, has always forbidden ORDER BY in view
> > definitions. Other than satisfying some people's need for doctrinaire
> > purity, the RDBMS users gained nothing by this restriction.
>
> >>By analogy of separating the logical from physical implementation, if
> >>you want to declare a separation of church and state, I'd think you'd
> >>need to mention both. Not to tout SQL but I took the above to mean that
> >>if a table were declared with an "INDEX", it shouldn't be allowed to
> >>participate in expressions of the relational algebra, which seems
> >>extreme and somewhat useless to me.
>
> > I think you're extrapolating Date's remarks to a point that he might not
> > agree with. A table with an index is still a table.
>
> > BTW, the doctrinaire folks among us will insist that SQL does not have INDEX
> > in the standard. But we all know that SQL databases use indexes to speed up
> > queries. And many application programmers appreciate being told what
> > indexes are present so that they can organize their queries for performance.
>
> > The doctrinaire people will say that the programmers have no need to know
> > index information, because it's not part of the logical model. In theory
> > they are right. In practice, it helps to provide them with it.
>

I do not believe this is a programmer-to-dba dba-to-programmer debate but a user-buying-a-crappy-product to editor-who-sell-bullshit- products

Considering that companies such as ORACLE, MICROSOFT and IBM which invested billion of dollars in developping product bill up to (100 000 $) per product license (ORACLE), knowledgeable users are perfectly in right to expect *some* quality from such vendors.

My two cents... Received on Tue Oct 09 2007 - 03:46:55 CDT

Original text of this message

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