Re: The job of a relational DBMS
Date: Mon, 30 Nov 2009 20:35:24 -0800
On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney <bignose+hates-spam_at_benfinney.id.au> wrote:
>Gene Wirchenko <genew_at_ocis.net> writes:
>> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
>> <bignose+hates-spam_at_benfinney.id.au> wrote:
>> >joel garry <joel-garry_at_home.com> writes:
>> >> 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.)
>> 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 clicodebecause 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.
>Transforming relational data into a non-relation is not the job of the
>relational DBMS, but the job of applications that receive relational
>data from the DBMS.
See above about sorting.
Gene Wirchenko Received on Mon Nov 30 2009 - 22:35:24 CST