Re: The Practical Benefits of the Relational Model

"mountain man" <prfbrown_at_magna.com.au> wrote in message news:<gHui9.36246$g9.103509_at_newsfeeds.bigpond.com>...

> Not quite. It requires the presence of separately addressable
> (from the apps environment) stored procedures within the (R)DBMS.

What is the "apps environment"? More precision would greatly help this conversation.

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

You want to know the amount of time that various DBMS venders have had externally exposed procedures/functions? What relevance does this have? Such capabilities are relatively old news. The industry flirted with thin client / fat server style applications using this methodology, but many moved away from it in favor of external programming languages. Why? Because the systems suffer from deep and severe limitations.

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

They certainly HAVE been developed commercially before. Many applications still are built like this, and most DBMSs have the ability to encrypt/obfuscate user code to protect IP.

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

How about client enforced constraints, defaults/ID generators, calculated columns, navigation & buffering, multi-table transactional implications, and other such matters? Today's DBMSs provide little help in handling these matters.

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

I think you are seriously down-playing the front-end portion of the application. This portion can easily constitute the majority of the development and maintenance time using today's common methodologies. What you are saying here reads to me as, "the software vendor will deliver a half-completed application." ;-)

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

Here are a few:
-Non real-time nature of integrity enforcement (when can you trust your data?).
-Arbitrary nature of which constraints are enforced where... -Imperative nature of procedure based constraint enforcement encourages bugs, degrades performance, reduces optimizability.

Though I have stated this in another posting (with no reply), let me state it again: if (big IF) all integrity constraints can be enforced by the DBMS, then we don't need an exception management system for integrity enforcement. If there is some application specific reason to put non-conforming data temporarily into the system, than such data should be separately modeled. That is precisely the task of application development: deciding what integrity constrains go where. Your proposed "exception management system" is therefore an application-level facility.

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

Your argument has jumped from discussing the concepts to basically, "I have seen people work around these problems." The database system is there to help us out as much as possible. The more integrity the system enforces, the less the application developer must enforce. The obviously desirable extreme is a system that enforces 100% of the integrity. Without resorting to arguments outside of the conceptual realm, please state why it would not be desirable for the system to enforce ALL integrity declaratively.

> 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

How about "Automate integrity checking".

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

The bottom line is that you are making an argument for a less general solution. The "exception management system" you espouse can be implemented in a "pure" DBMS that can enforce ALL integrity. However, not all benefits of such a DBMS can be provided by an exception management system.

> 1) 1st software system environment: Hardware OS and net OS
> 2) 2nd software system environment: (R)DBMS <<-------|
> 3) 3rd software system environment: (db) applications -->|

There are many different ways we could draw lines between conceptual systems. Calling the "3rd environment" the "application" is bad terminology. The sum of all systems that together provide the service constitute the software application.

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

I presume you are including the user interface in this "3rd environment." Surely you aren't suggesting the elimination of that! Not only does the 3rd environment need to stay (so the application has a client), but environments 1 and 2 could actually be combined to further reduce complexity. Combining the DBMS with the OS has been done in various forms over the years with varying levels of success (AS/400). The minimal number of environments cannot be reduced below 2 unless we cram all of the users into the server room and let them duke it out. :-)

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

So, "once we keep those users out of the application, things can really begin to progress!" ;-)

--
Nathan Allan