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

From: mountain man <hobbit_at_southern_seaweed.com.op>
Date: Thu, 14 Apr 2005 08:53:12 GMT
Message-ID: <Ybq7e.10713$5F3.5674_at_news-server.bigpond.net.au>


"Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message news:0ffq515ju40r9lra6hmc5iggfje429f316_at_4ax.com...
> On Sun, 10 Apr 2005 12:55:46 GMT, "mountain man"
> <hobbit_at_southern_seaweed.com.op> 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.
>
> And there are a number of different species of database objects and
> program objects. Some database objects are programming objects.
>
>>The relational model of the data is a very good reference for the
>>management of data and its integrity within the RDBMS, but it
>>is totally useless for program objects
>
> This is completely wrong.

So you assert.

Consider an RDBMS supporting a large suite of database application programs created in any programming langauge. What formal relations exist between said suite of program objects and the RM of the data?

>It would be very useful to include
> relational extensions in the application programming languages.

Yes, that would be nice.
but is this happening on any scale at present?

>>, and thus is restricted in
>>issues involving the coordination of both data and program
>>objects.
>
> This is an implementation issue and it has nothing to do with the
> Relational Model.

This is a chicken and egg straw man. Surely the seeds of the implementation are in the model prior to implementation, just as the model is continually re-invoked to as the data structures evolve over time, well after implementation.

>>Since the emergence of addressable stored procedure objects
>>within the RDBMS vendor software at the end of the 1990's
>>program objects have lived within the RDBMS.
>
> Indeed, and they are perfectly integrated with the other database
> objects like table variables.

Yes.

>>Given that such an environment exists whereby both data objects
>>and program objects are physically stored within the RDBMS
>>has anyone seen recently any emergent models that address both
>>these objects in a consistent manner?
>
> We don't need any new model of anything

Your vantage point on the environment is noted.

>, it is an implementation
> issue.

So you assert from your POV.

As is your traditional insistence to split theory and implementation such that one is not really concerned with the other.

Fortunately, my philosophy on the matter is the opposite, and I perceive that theory and implementation are forever mixed, like the black and white bands at a fractal basin boundary.

>We only need to integrate database variables in the
> applications.

This is an efficient mechanism, and may be milestones ahead of other solutions, but it is not the end of the road to an
improvement of the current theory.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Thu Apr 14 2005 - 10:53:12 CEST

Original text of this message