Prev: Oracle forms and windows hibernate
Next: The job of a relational DBMS
From: Ben Finney on 30 Nov 2009 16:50
joel garry <joel-garry(a)home.com> writes:

> On Nov 27, 3:12 pm, Ben Finney <bignose+hates-s...(a)benfinney.id.au>
> wrote:
>
> > and then use a function or user application to process the relation
> > into whatever output text you like for the report. Turning relations
> > into reports isn't the job of the DBMS.
>
> So what is the job of the DBMS?

The job of a relational DBMS is to implement the relational model, by
implementing a logical set of rlations in a physical database
implementation, and to provide an interface to applications for managing
and querying the relations in that database. The output of those
operations should be either status messages or new relations.

> From wikipedia (just 'cause it was the first thing that popped up in
> google, you are welcome to cite others):

I'm paraphrasing my understanding of the writings of E. F. Codd, C. J.
Date, and Hugh Darwen.

> "A Database Management System (DBMS) is a set of computer programs
> that controls the creation, maintenance, and the use of the database
> with computer as a platform or of an organization and its end users."

That seems fair, since it's not restricted to relational DBMS. I wasn't
specific before about the fact that we're talking about *relational*
database management systems behaviour, but I believe that's been the
topic consistently through this thread.

> Turning relations into reports may or may not be the job of the
> database

It's not; the job of the database is to be an implementation of a data
model. As you imply by making the distinction, DBMS ≠ database.

> but by definition it quite well can be the job of the Database
> Management System.

Not the relational DBMS. A DBMS might do *more* than the job of a
relational DBMS, but the distinction I'm making is that one should not
expect to find that behaviour in a relational DBMS since that's not its
job.

> There are some things apps may do better, and some things the DBMS may
> do better. Which things may be debatable, but saying either should do
> all or neither is wrong.

The output of a query into a relational DBMS should always be a relation
(or a status message). It's up to the application to use non-relational
means to turn that relation into whatever other form it requires.

> Can't a function be part of the DBMS?

A non-relational function shouldn't be part of a relational DBMS, no. An
application can *store* its non-relational functions in the *database*,
of course, and access them there; but database ≠ DBMS.

--
\ “Those who write software only for pay should go hurt some |
`\ other field.” —Erik Naggum, in _gnu.misc.discuss_ |
_o__) |
Ben Finney
From: Gene Wirchenko on 30 Nov 2009 21:17
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. An
>application can *store* its non-relational functions in the *database*,
>of course, and access them there; but database ? DBMS.

Addition of integral values is a function mapping two integral
values to an integral value. Note the lack of a relation in the RDBMS
sense. I think it would be a very useful thing for an RDBMS to have
it.

(How do you more precisely make the division between in and out?)

Sincerely,

Gene Wirchenko
 | 
Pages: 1
Prev: Oracle forms and windows hibernate
Next: The job of a relational DBMS