Re: The job of a relational DBMS

From: joel garry <>
Date: Tue, 1 Dec 2009 17:23:34 -0800 (PST)
Message-ID: <>

On Dec 1, 11:48 am, Shakespeare <> wrote:
> joel garry schreef:
> > On Nov 30, 8:35 pm, Gene Wirchenko <> wrote:
> >> On Tue, 01 Dec 2009 13:45:44 +1100, Ben Finney
> >> <> wrote:
> >>> Gene Wirchenko <> writes:
> >>>> On Tue, 01 Dec 2009 08:50:34 +1100, Ben Finney
> >>>> <> wrote:
> >>>>> joel garry <> 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.

Kinda. The tuples of a relation (AKA rows in a table) have no order, which leads to no order on the attributes. Applications use queries to access data. So we wind up with confusion between application access and relational inquiry with SQL. It makes no sense to maintain that SQL (of any variety) only does or should do relational operations. It happens to be the single language of both relational queries and applications, using the relational terminology. So Ben is both right and wrong about user applications being the one to process the data for users, as SQL confounds the difference. I used to (like, 15-20 years ago) think this was a big shortcoming of SQL, since it does only part of the user application. Now that the various extended SQL's can do all of this (even *gasp* html and xml), and the standardization is close enough to allow it to be used as a data access language by various tools, that is less of an issue, though the basic differences between engines makes for a different problem. I think we can all agree that the popular engines distance themselves from relational theory to a great degree - but I don't think that leads to judging these distances as bad at all. I know that is flamebait in comp.databases, but, well, I didn't start the crossposting.

As far as analytics, I think it is good to be able to shove some processing into the sql engine, but I think we are also seeing that it is hard to predict that performance will be better by doing that, as a generality. Basically the same problem as forcing order into group by, there are times we as programmers know better how to manipulate the data, especially sorting and ordering mass quantities.


-- is bogus.
"What does HTML stand for?"
"I don't, ah, HoT Man Links?"  - heard on radio call-in trivia
Received on Tue Dec 01 2009 - 19:23:34 CST

Original text of this message