Re: the relational model of data objects *and* program objects
Date: Thu, 21 Apr 2005 08:15:51 -0400
Message-Id: <07ikj2-bti.ln1_at_pluto.downsfam.net>
mountain man wrote:
> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
> news:iluhj2-pd1.ln1_at_pluto.downsfam.net...
>> mountain man wrote: >> >>> This thread concerns the relationship between data objects >>> and program objects and the model used to conceptualise >>> the totality of relationships within and between the objects. >>> >>> Cursory study of the ecology of all computer database systems >>> reveal the existence of a number of different species of objects, >>> data objects and program objects being two. >>> >> >> You know, we never talked about testing and version control. >> >> Assertion: complete specification of actions in meta-data, as described >> elsewhere in the thread, is the easiest way to produce testing, and it >> also >> converts version control into an entirely new animal. >> >> Also, dependencies can be tracked very well. If somebody says, "We need >> an >> A/R module in this new system, but not A/P or G/L", you can run a SELECT >> out of the dd for all objects that depend on the A/R subs ledger, and >> this is the spec that must be fed to the builder.
>
> A good example.
>
> The point is that the database is already "the" centralised resource" in
> an environment which consists of (sometimes) a huge amount of program
> objects, a huge organisational structure and a great deal of concurrent
> change at various levels.
>
> Most modern (r)dbms software already provides for automatic detection
> of the programs being run against it. If all these programs existed in a
> register
> then you would immediately have the ability to statistically determine the
> actual useage of each program object --- and this is useful at times.
>
> However, as you point out above, the big (and usually unseen) resource
> depleting task is change management of the program suite *and* the
> database schema, and their coordination. There is no (general) theory
> for this because of historic rampant diversity of program code.
Well, I would humbly submit that I have shown a strong candidate :) But as SDS is a young and small company...
>
> But my point is this ... history is changing and we are seeing a migration
> of the object code out of the client environment (in whatever programing
> language it was written in) and into the RDBMS environment in the form
> of stored procedures.
>
> In the end it will be conceivable to think of a database as having all the
> data and all the programs. At that stage, with all the object code
> defined within the rdbms one would expect there to be a methodology
> whereby such an arrangment can be effectively managed.
In our shop the future is now. But you can only get there if describe the application entirely in meta-data, and then map software development tasks to data handling jobs. "Managing Code" is simply not an effective strategy, because code and data are so totally different. In the end, the architecture will have one bow to the other. Data is easier than code, data wins.
>
> And at the basis of such a methodology is a database table related to the
> component objects in service within the environment, serving as an
> application register (for all processes).
Registering and tracking the code in the database will not get us there. This describes nothing more the version control, and nothing about version control changes if you migrate the code into the server.
>
>
>
> Pete Brown
> Falls Creek
> Oz
> www.mountainman.com.au
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Thu Apr 21 2005 - 14:15:51 CEST