Re: the relational model of data objects *and* program objects
Date: 16 Apr 2005 18:08:05 -0700
Message-ID: <1113700085.252829.287860_at_o13g2000cwo.googlegroups.com>
mountain man wrote:
> "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)
This topic is one of my hot buttons too so I've been following your reasoning with interest.
> >>>>
> >>>
> >>> ...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.
And after as many years (and then some), having similar concerns, I'm leaning today almost the opposite -- to remove the logic from a proprietary dbms product and use a much leaner layer to persist data, writing constraints and derived data definitions in the same language as applications. This way complete applications can be written without SQL, for example.
>
> That way everything can be defined within the DBMS
> layer once, and for all builds. All code is SQL.
I suspect it is impossible to do this without marrying yourself to a specific dbms tool, right?
> The RDBMS software has the capacity to house 100%
> of the data *and* 100% of the organisation's (app)
> code,
each SQL-DBMS would do this differently so that you could not simply take your application and move it. In my approach, the same would be true of the language chosen. However, I can choose a language that doesn't come with annual maintenance costs with my approach (e.g. Java). It might be possible to do what you want to do with PostgreSQL, perhaps Ingres? Are you choosing something that will cost you a mint from here to eternity?
> and this arrangement, from the theoretical
> perspective IMO reflects the "smallest number of
> moving parts".
but SQL, brother? If I put in order the languages I would want to use to write and maintain an entire (set of) application(s), SQL would fall very close to the bottom for me. Since there isn't one version of SQL out there, which flavor(s) will you choose? --dawn
> Pete Brown
> Falls Creek
> Oz
> www.mountainman.com.au
Received on Sun Apr 17 2005 - 03:08:05 CEST