Re: theory and practice: ying and yang

"erk" <eric.kaun_at_gmail.com> wrote in message news:1117632046.632868.13740_at_g49g2000cwa.googlegroups.com...
> 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?

So that no code has to exist external
to the RDBMS software environment.
(code = application software code)

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

The potential to be called separately by executable objects, standard application software code, for example, resident on a client machine, invoked by a user.

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

The tendancy to shift client objects from the client and then run them on an application server is a separate trend.

I am looking at the global collection of code. At some stage prior to the mid-nineties (emergence of addressable sprocs) there existed ZERO application code within the RDBMS, and 100% in the external environment.

Since that time, the use of sprocs has increased, and there exists (it could argued) now some apportionment of where the code resides, say 30% in the RDBMS and 70% as executable objects on the client, or on the application server.

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

Yes, this would make sense. But the stored procedures are just constructions of SQL, and can be created, edited, etc by users as well.

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

I have tool which provides a service level channel between the user and a register of stored procedures. This tool's role in life it to receive instructions from the user (mouse), send these to the RDBMS with instructions to run a specific sproc. The results set of the sproc get returned to the tool and displayed to the user. A web enabled tool exists, yes.

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

Can you give me a good example of such?
Many thanks,

-- 
Pete Brown
Falls Creek
OZ
www.mountainman.com.au