Re: The Practical Benefits of the Relational Model

> 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:

The technology to effect this type of system has been in place for decades, and yet this solution has not been developed. 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. 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.

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. 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. 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.

Regards,
Bryn Rhodes
Alphora Received on Thu Sep 19 2002 - 17:11:42 CEST