Re: the relational model of data objects *and* program objects
Date: Sun, 17 Apr 2005 03:06:38 GMT
Message-ID: <2pk8e.13825$5F3.9036_at_news-server.bigpond.net.au>
"dawn" <dawnwolthuis_at_gmail.com> wrote in message
news: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.
Despite your apparent totally opposite approach I believe in fact that our reasons for pursuing these respective paths is probably the same.
Essentially both pathways strive to reduce coordination of the redefinitions required in writing code for multiple software layers. (ie: the DBMS and the app layers)
This reduces to a smaller number of "moving parts" when the consideration of long-term change management is brought into the argument.
>> 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?
At the moment, from the theoretical perspective, the dbms itself
needs to have these requirements:
a) a native language (such as SQL), and
b) the capacity to store separately addressable
objects (written in this code) within the dbms.
>> 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.
This probably depends on how the SQL code were written. Translators between platforms might perform much of the hack work, but in general each situation of code would need to be examined individually.
OTOH, moving the code between similar SQL-DBMS actually reduces to the task of importing (or restoring) a database of stored procedures.
> 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?
The prototype was put together using MS's SQL Server TSQL and works fine. It may be possible to construct this solution using the above options, so long as they satisfy the two mandatory requirements (a) and (b) above.
>> 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.
Well, I guess it depends on your experience with SQL. Personally I have never yet found a problem too difficult to resolve using TSQL within the MS SQL Server environment, but that is only because of the historical path that I myself have "trod". Each of us here, and everywhere else have our "historical trail" that affords (at least) part of our perspective.
> Since there isn't one version of SQL
> out there, which flavor(s) will you choose? --dawn
The theory of what I describe would use the SQL available on the native (R)-SQL-DBMS, so long as it can be stored within that dbms software as separately addressable stored procedures.
Pete Brown
Falls Creek
Oz
www.mountainman.com.au
Received on Sun Apr 17 2005 - 05:06:38 CEST