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

erk wrote:
> 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.

The goal is flexibility and stewardship (better bang for the buck, for example) in software development and maintenance. I think SQL is one of the obstacles to that, but not the only one.

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

If I'm going to "spec" constraints and other metadata, I want multiple vendors to handle those specs identically so I'm not stuck with a single compiler/interpreter of my specification. I don't want to be married to a single dbms vendor but also important is that I don't want to be married to both a database vendor plus another language (so mm's approach is addressing the same problem, but he is OK with the marriage to a single vendor implementation of the SQL language, while that doesn't sit well with me at this point).

Additionally, the constraints and other metadata must be accessible to any UIs and web services interfaces as well as to the database interface. --dawn

>
> - erk
Received on Tue Apr 19 2005 - 00:56:02 CEST