Re: theory and practice: ying and yang

mountain man wrote:
> The relational model speaks about data and its schema but is mute
> about the application software layer, which has been sitting in the
> s/w protocol stack above the DBMS software, since the year dot.

So would you advocate keeping stored procedures in a relational structure, so that they can be queried and manipulated as is data?

> My observation is that, since the emergence of addressable stored
> procedures within the (R)DBMS layer, systems are using this
> approach more and more.

Addressable? As opposed to triggers?

> Essentially you can generalise this observation, with reference to
> the protocol stack and say that industry is following an increasing
> trend in that the (application) code is being migrated from the
> (client and/or server) application software layer, and into the
> (R)DBMS layer.

I don't think it's that simple - there's an (at least) equally strong impetus to deploy code in a DBMS-independent application server layer.

> My thesis is that if you take this migration to its logical
> conclusion there may be achievable an optimal stage in
> which *all* application software in internal to the DBMS
> in the form of stored procedures.

And if it's internal, I'd say that the system catelog should allow manipulation of these procedures in much the same way as it should allow manipulation of other relations, and of data itself.

> > 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.
>
> Absolutely preferable, because it entirely OBVIATES the client.
> End of story. There is no client required, and therefore no
> middleware required, at all. Minimal number of moving
> parts in that all the code and data are being defined once
> and for all in ONE SOFTWARE LAYER.

You still have an HTML client, right? Granted that it's much easier to manage - to the extent that users have been accepting ergonomically and aesthetically impoverished interfaces for years, because it allows quicker deployment and easier management of applications.

> Theoretical limitations about SQL and Views by Date et al are not
> limitations at all from my perspective, because views are not
> essential. End of story. ;-)

Views are not essential, but are darned useful for introducing part of the logical-physical separation that SQL basically ignores.  

• Eric