Re: the relational model of data objects *and* program objects
Date: 18 Apr 2005 07:30:24 -0700
Message-ID: <1113834624.557471.138120_at_z14g2000cwz.googlegroups.com>
dawn wrote:
> 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.
If eliminating SQL is your goal, then you've succeeded by definition. I have no objection to the language chosen to "write constraints" (though it shouldn't be procedural), but why is it important that the language to "derive data definitions" and write constraints be separate from the "database"?
- erk