Re: theory and practice: ying and yang
Date: Wed, 01 Jun 2005 09:39:05 GMT
Message-ID: <Zmfne.9091$BR4.7391_at_news-server.bigpond.net.au>
>>which has been sitting in the
>>s/w protocol stack above the DBMS
>>software, since the year dot.
>
> ???
The generalised database software environments may be reasonably depicted as follows, E3 being supported by E2, supported by E1, supported by E0 as follows:
E4 - other application software (not related to DB) E3 - database application software E2 - (R)DBMS software E1 - OS and NWOS software E0 - hardware and ROM.
Date has a similar definition, but lacks any formalism or structure .... Database Systems [Date, 7th Ed]: page 5 .....QUOTE:
"FIG 1.4 is a simplified pic of a database system. It is meant to show that a database system involves four major components: data, hardware, software and users".
>>My observation is that, since the emergence of addressable stored
>>procedures within the (R)DBMS layer, systems are using this
>>approach more and more.
>
> But the stored procedures are a part of the "schema".
You are confusing system dedicated stored procedures (such as those perhaps responsible for update, delete, replication, etc --- ie: low level database tasks) with stored procedures that have been created in response, for example, to a reporting need, at the application level.
A stored procedure whose sole responsibility in life is to display the debtors trial balance as at today, I would not consider as part of the "schema", rather as part of the "application".
My point is not that stored procedures are being used to perform the low level database tasks, but that there is an increasing trend to use stored procedures to do application layer tasks (such as reporting).
IOW, the intelligence (or lines of code) are effectively being slowly migrated out of executable programs on the client environment, into stored procedures on the RDBMS environment.
-- Pete Brown Falls Creek OZ www.mountainman.com.auReceived on Wed Jun 01 2005 - 11:39:05 CEST