Re: The Practical Benefits of the Relational Model

Mountain Man,

I'm going to spend a little time reading your web papers before responding.

In the meantime, reacting to just your message,

I think there's an alternative formulation, that I'll call the "Java approach". That is to separate the
"locus of compilation" from the "locus of execution". That is, the Java source code gets written, maintained, and compiled at one location on the net, while the executable code is stored, retrieved, and executed under the auspices of the RDBMS.

I think there are important problems with that approach, but the benefits are large enough so that we will likely be seeing it for a decade or so.

--
Regards,
    David Cressey
    www.dcressey.com
"mountain man" <prfbrown_at_magna.com.au> wrote in message
news:NM9i9.35590$g9.100856_at_newsfeeds.bigpond.com...


> "David Cressey" <david_at_dcressey.com> wrote in message


> news:5Y0i9.96$0I3.5569_at_petpeeve.ziplink.net...

>

> > At this stage, my question is,  "what makes sense, going forward?"

Should


> a

> > new language be developed,  that takes on a different from SQL's


mission,


> > but one that overlaps SQL's mission?  It sounds, from the discussion of


> "D"

> > and its family of languages, as though the answer is "yes",  at least

for


> > some of the important authors.  If a new language is developed, is that


> > going to increase or decrease the total amount of confusion generated by

> the

> > present plethora of languages?  Does anybody care?

>

>

> I agree with your earlier comments about SQL being there at the

> right time and place.  You could probably summarise this by the

> remark that all computer systems software "evolves" in time.

>

> Rather than ask the question on the future evolution of new RDBMS

> languages, I have taken the approach that SQL, in combination with the

> management services provided by most RDBMS (eg: task scheduler)

> will be able to handle 100% of the problems encountered in realtime.

>

> Therefore I do not see evolution of SQL or of any language capacity

> to be of any real importance in the entire future picture of things.

> Rather, I see the important evolutionary trends as they relate to the

> (site) management of the RDBMS environment.

>

> Specifically, I see an entire new generation of database application

> "software" being written _exclusively_ using the RDBMS native

> utilities (largely stored procedures).   The end-point of this evolution

> is a shift in the location of the (db) applications software environment.

>

> It will disappear from the current desktop/apps server environment

> external to the RDBMS, and move internal to the RDBMS.  It will

> evolve in this manner because it is far easier to manage two systems

> software environments than three.   For further detail see:

>

> http://www.mountainman.com.au/software/history/it7.html

> http://www.mountainman.com.au/software/history/it8.html

>

>

>

>

> Farmer Brown

> Falls Creek

> OZ

>

>

>

>

>

>