Re: theory and practice: ying and yang

From: Paul <paul_at_test.com>
Date: Tue, 31 May 2005 01:18:10 +0100
Message-ID: <429bad41$0$2349$ed2619ec_at_ptn-nntp-reader02.plus.net>


mountain man wrote:

>>Do you have a concrete example of a simple stored procedure, and how
>>you'd want this to be handled by your ideal DBMS?

>
> My claim is that the entire application software environment
> can be reduced to a series of stored procedures. Here is
> the classic example, for the Northwind Trading Company:
> http://www.mountainman.com.au/software/southwind/
>
> In this example, we have a database (southwind) containing
> a series of stored procedures which act as the application
> software components for the Northwind data.
>
> In this arrangement both the data and *all* programs (ie: apps)
> can be confined to the environment of the database system.

OK, but the stored procedure *are* stored within the DBMS, so doesn't this contradict your claim that the relational model can't handle the stored procedures?

Isn't what you've done standard practice in designing enterprise database reporting systems? i.e. to have a stored procedure (or in an ideal world, a view) for each report?

Are you saying that this method is preferrable to the "fat client" or "middleware" method, where you have business logic held outside the database in things like Cognos, Business Objects, or Crystal Reports? I thought this was pretty much the same as most other people think.

Is the point you're making that the procedural language used in stored proecedures isn't part of the relational model? In which case all the stored procedures you have could be replaced with views, which are part of the relational model. This approach would only break down for the cases I mentioned before i.e. when you have several data manipulation statements in a single transaction. But I don't see any of these cases in your example application.

Paul. Received on Tue May 31 2005 - 02:18:10 CEST

Original text of this message