Re: The job of a relational DBMS
Date: Tue, 1 Dec 2009 09:43:35 -0800 (PST)
Message-ID: <04c6febb-e0ef-43cc-8a35-e8f8f584be46_at_a32g2000yqm.googlegroups.com>
On Nov 30, 8:35 pm, Gene Wirchenko <ge..._at_ocis.net> wrote:
> On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
>
>
>
> <bignose+hates-s..._at_benfinney.id.au> wrote:
> >Gene Wirchenko <ge..._at_ocis.net> writes:
>
> >> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
> >> <bignose+hates-s..._at_benfinney.id.au> wrote:
>
> >> >joel garry <joel-ga..._at_home.com> writes:
>
> >> [snip]
>
> >> >> Can't a function be part of the DBMS?
>
> >> >A non-relational function shouldn't be part of a relational DBMS, no.
>
> >This was far too broad, I now see. Originally it was in the context of a
> >*query* returning a non-relational result, which is really as far as I
> >should have taken it.
>
> I think you still have problems with the division. (I do not
> claim to be able to define the split myself. I know how difficult it
> can be to rigourously define something.)
And perhaps relvars can torture non-relations to relations. But this is all too deep for me. I mostly agree with you guys. There should be clear delineations between relational and non-relational parts of systems, as well as standard SQL versus extensions and procedurals.
>
> >> Addition of integral values is a function mapping two integral
> >> values to an integral value.
>
> >Right; of course, there are heaps of functions operating on attribute
> >values that can be used *within* relational operations to modify the
> >relation that will be returned. Such functions definitely belong as part
> >of the relational DBMS.
>
> >What I was trying to express was that relational operations — like the
> >various relational operations that ‘SELECT’ implements — should only
> >return data as relations (they might also return status responses). They
> >should never return non-relation data.
>
> A relation does not have order. This would not be a relation
> select clicode,cliname from clients order by clicode
> because of the order by clause.
>
> Having to go through a sort stage when the DBMS might well have
> been able to easily handle it would be counterproductive.
>
> For example, a group by in SQL forces the result to be sorted by
> the grouping unless otherwise overridden.
This is certainly wrong in Oracle, and ought to be wrong everywhere else. I don't say that as an Oracle wonk, but rather because ordering needs to be explicit by definition.
jg
-- _at_home.com is bogus. http://codeoffsets.com/Received on Tue Dec 01 2009 - 11:43:35 CST