Prev: The job of a relational DBMS (was: Sql request)
Next: Pivot table Query - Need help in building correct logic
From: Ben Finney on 30 Nov 2009 21:45
Gene Wirchenko <genew(a)ocis.net> writes:

> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
> <bignose+hates-spam(a)benfinney.id.au> wrote:
>
> >joel garry <joel-garry(a)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.

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

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.

--
\ “Anyone who believes exponential growth can go on forever in a |
`\ finite world is either a madman or an economist.” —Kenneth |
_o__) Boulding |
Ben Finney
From: Gene Wirchenko on 30 Nov 2009 23:35
On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
<bignose+hates-spam(a)benfinney.id.au> wrote:

>Gene Wirchenko <genew(a)ocis.net> writes:
>
>> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
>> <bignose+hates-spam(a)benfinney.id.au> wrote:
>>
>> >joel garry <joel-garry(a)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.

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.

Sincerely,

Gene Wirchenko
From: Ben Finney on 30 Nov 2009 23:52
Gene Wirchenko <genew(a)ocis.net> writes:

> On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
> <bignose+hates-spam(a)benfinney.id.au> wrote:
> >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.

Hmm. I'm not sure it's right to say the result would not *be* a
relation; but I certainly take the point about 'ORDER BY' requesting
order be imposed on an orderless relation.

I guess I would want to say that a 'SELECT' result, though it is ordered
(either implicitly or at the request of the query author), is
nevertheless *compatible with* a relation, as distinct from the way that
the desired “omit some of the values to make the report look closer to
what I want” that started this thread is incompatible with relations.

> Having to go through a sort stage when the DBMS might well have
> been able to easily handle it would be counterproductive.

This is certainly a good point, and I agree.

I'm glad I've been asked about my definitions, it has led to some
clarification. Does anyone have a better definition they'd like to offer
of what “the job of a relational DBMS” is?

--
\ “I do not believe in immortality of the individual, and I |
`\ consider ethics to be an exclusively human concern with no |
_o__) superhuman authority behind it.” —Albert Einstein, letter, 1953 |
Ben Finney
From: joel garry on 1 Dec 2009 12:43
On Nov 30, 8:35 pm, Gene Wirchenko <ge...(a)ocis.net> wrote:
> On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
>
>
>
> <bignose+hates-s...(a)benfinney.id.au> wrote:
> >Gene Wirchenko <ge...(a)ocis.net> writes:
>
> >> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
> >> <bignose+hates-s...(a)benfinney.id.au> wrote:
>
> >> >joel garry <joel-ga...(a)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
--
@home.com is bogus.
http://codeoffsets.com/

From: Shakespeare on 1 Dec 2009 14:48
joel garry schreef:
> On Nov 30, 8:35 pm, Gene Wirchenko <ge...(a)ocis.net> wrote:
>> On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
>>
>>
>>
>> <bignose+hates-s...(a)benfinney.id.au> wrote:
>>> Gene Wirchenko <ge...(a)ocis.net> writes:
>>>> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
>>>> <bignose+hates-s...(a)benfinney.id.au> wrote:
>>>>> joel garry <joel-ga...(a)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.

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.
>
> 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
> --
> @home.com is bogus.
> http://codeoffsets.com/
>

Shakespeare
 |  Next  |  Last
Pages: 1 2 3 4
Prev: The job of a relational DBMS (was: Sql request)
Next: Pivot table Query - Need help in building correct logic