Re: the relational model of data objects *and* program objects

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

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.

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

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Thu Apr 21 2005 - 09:04:46 CEST