Re: The job of a relational DBMS

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