Re: The job of a relational DBMS

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

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

I thought that one was about the order of attributes, not rows.

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

Shakespeare Received on Tue Dec 01 2009 - 13:48:33 CST