Re: The Practical Benefits of the Relational Model
Date: Fri, 20 Sep 2002 11:43:58 +1000
Message-ID: <gHui9.36246$g9.103509_at_newsfeeds.bigpond.com>
> > 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/LittleSteps
> The technology to effect this type of system has been in place for
> decades, and yet this solution has not been developed.
Not quite. It requires the presence of separately addressable (from the apps environment) stored procedures within the (R)DBMS.
Was this available so long ago? I doubt it would have been more than a decade, but would indeed be interested to learn the answer to the following question ....
*******[Open Question]*********************************When did each of the major (R)DBMS vendors introduced the functionality of separately addressable stored procedures which could be called directly (and with input/output parameters) from a call in the applications environment?
Oracle: ?
IBM: ?
Microsoft: about 1994
Other (R)DBMS vendors: ?
*******[Close Question]*********************************
to continue, however ...
More importantly, it requires the software supplier to convert all his/her code to the form of (R)DBMS stored procedures (ie: 100%). and having all the source code visible to the end client DBA, etc.
Such solutions have not before been developed commercially before because it is an extremely OPEN SOURCE approach, and software vendors get terribly skittish about such an animal.
>Primarily
> because black-box systems such as the one you describe where all the
> code is 'inside the RDBMS' (as an aside, I wish you wouldn't call them
> RDBMSs, they aren't, they are SQL-based DBMSs) does not lend itself to
> client application development.
On the contrary, I am making such a product available and one of the more important benefits it has is the ability to be able to rapidly develop and maintain client applications.
> A software system must be provided
> such that the business rules (organizational intelligence if you
> prefer, same thing) enforced by the server can be seamlessly and
> transparently enforced by the client without additional development
> effort.
Under my proposed arrangement, if the client had contracted with a software vendor for the provision of a new software package, then the vendor will simply provide the client with a database within which reside the database stored procedures which define - in totality - the new application (less the portal).
The software system so provided does not require an applications environment out on the scattered desktops or applications servers as it is totally catered for within the (R)DBMS.
It works fine.
> As for integrity, the idea that stored procedures can be run at
> pre-determined intervals to validate data is nothing new, nor is it
> exceptionally clever.
I have not seen any arguments to the contrary.
> Integrity is the most important aspect of any
> given database system, and the fact is that SQL-based systems fall far
> too short in this arena (and many others) to present a viable option
> moving forward.
Your first statement is accurate, concerning the central role of data integrity, but your second statement needs to be qualified a little more. On face value, to me, it looks just plain wrong. My perspective is from that of an IT manager who has seen a number of SQL based systems that have been engineered to an optimum level of automation, including data integrity exception management.
In my experience, it is not the system falling far short but the custodian engineers and managers of that system. There are always work arounds. It is the nature and the demand of the production environment. Nothing is perfect. Be prepared. Automate integrity exception checking. etc
>A new language must be built (and has been, I might
> add) which can express these integrity constraints without resorting
> to triggered procedures. Mountains of error-prone, procedural code in
> proprietary DBMS dialects would be completely eliminated if the
> database language simply allowed the expression of database-wide
> integrity constraints. This is the goal, and this is the future of
> database management systems.
Perhaps from your perspective it is. It really depends on the importance you attach to the mechanism(s) available to address the maintenance of database integrity constraints and the means by which you ultimately resolve these issues 1) today in a production environment and 2) in some future technology.
However, from my perspective, the goal of the evolution of computer software systems will be their ability to discard the entire (db) applications software system environment as does a command module eject its primary fuel booster module in an outbound trajectory.
Environments 1 and 2 and known stable reliable products which may have as few as a dozen vendor combinations covering more than 95% of all (R)DBMS sites.
Environment 3 is a rampant uncontrolled flaming elephant that has been in service since the very beginning and needs to be lead to retirement and pasture.
Once the 3rd environment is no longer, the evolution of technology running now exclusively within the 1st and 2nd computer software environments will move into a new evolutionary phase of the analytical machine technology.
Only then will it commence to pick up speed and a true direction, and a that stage, things will start moving ahead again.
But for now, I think many of us are simply sitting back and watching the same old circus show.
> Regards,
> Bryn Rhodes
> Alphora
Best wishes,
Farmer Brown
Falls Creek,
Australia
www.mountainman.com.au
Received on Fri Sep 20 2002 - 03:43:58 CEST