Re: theory and practice: ying and yang
Date: Mon, 30 May 2005 23:32:45 GMT
Message-ID: <xoNme.7531$BR4.442_at_news-server.bigpond.net.au>
"Paul" <paul_at_test.com> wrote in message
news:429aedb5$0$578$ed2619ec_at_ptn-nntp-reader03.plus.net...
> mountain man wrote:
>>>>>>Date ignores the proofs of Godel and Chaitin.
>>>>>
>>>>>This is plain nonsensical.
>>
>> http://www.mountainman.com.au/software/history/relational_model_incomplete.htm
>
> this is from the above link:
>
>> Relational Theory has a Godel-like incompleteness
>> that may be simply specified:
>>
>> The Relational Model of the data is incomplete
>> because it cannot adequately address
>> RDBMS stored procedure object data.
>
> This may be an incompleteness of the relational model, but I don't think
> it's right to call it a "Godel-like" incompleteness. That has a very
> specific theoretical logical meaning, whereas the use of stored
> procedures is more of a software engineering issue.
>
> I guess you're thinking of a situation where you want to, say, do an
> UPDATE and a DELETE in one transaction? Classic example being the
> transferral of money between accounts. I suppose this issue only arises
> with things that change the contents of the database.
>
> Now some existing DBMSs certainly store the definitions of stored
> procedures in tables, but I guess this isn't what you're meaning.
>
> 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.
From a cost and coordination perspective, this is huge, because change management is not now spread across two software protocols (eg: DBMS and whatever your coding the application environment with [VB,C?]), but is unified within the DBMS.
-- Pete Brown IT Managers & Engineers Falls Creek Australia www.mountainman.com.auReceived on Tue May 31 2005 - 01:32:45 CEST
