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

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:cvp4j2-gsb.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message
>> news:60l3j2-g8s.ln1_at_pluto.downsfam.net...
>>> mountain man wrote:
>>>
>>>>> So first we need to identify such dual things in programs, data and
>>>>> processes.
>>>>
>>>> I have thought about this, and concluded that the greatest
>>>> (and single most cost-incurring expense) related to database
>>>> systems is RE-definition of data ---- once in the database,
>>>> and again in the code (wherever the code may actually reside)
>>>>
>>>
>>> ...and once again in the next layer of the code, as in:
>>>
>>> 1) db layer
>>> 2) web service layer
>>> 3) browser layer
>>>
>>> This is why the One True Data Dictionary must exist outside of all of
>>> them,
>>> and be used to implement all of them. If the spec is both
>>> machine-readable and human-readable, mores the better.
>>
>>
>> Another alternative is to have the data dictionary defined
>> within the database systems software once and definitively
>> and all other software layers reference this. Of course the
>> db layer could publish this into other layers.
>>
>
> I've tried this in at least two forms and decided it was better to "cache"
> a
> copy of the dd in the web layer in its own language. Makes for far
> simpler
> layer-boundary code. The delta-dd occurs only during a build, in fact a
> build defines the delta-dd event, so at that point you put the data into a
> form that is appropriate for the other layers and can safely leave it
> there
> unaltered until the next build.

After more than 2 decades in the business I decided it would be better to migrate every single bit of application code external to the database, into the database as SQL stored procedures. A generic service level portal tool acts as the user interface and is driven by the stored procedures.

That way everything can be defined within the DBMS layer once, and for all builds. All code is SQL.

The RDBMS software has the capacity to house 100% of the data *and* 100% of the organisation's (app) code, and this arrangement, from the theoretical perspective IMO reflects the "smallest number of moving parts".

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Sat Apr 16 2005 - 15:07:03 CEST