Re: The job of a relational DBMS
Date: Tue, 01 Dec 2009 15:52:48 +1100
Gene Wirchenko <genew_at_ocis.net> writes:
> On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
> <bignose+hates-spam_at_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 FinneyReceived on Mon Nov 30 2009 - 22:52:48 CST