Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: The Practical Benefits of the Relational Model

Re: The Practical Benefits of the Relational Model

From: mountain man <>
Date: Sat, 21 Sep 2002 09:46:18 +1000
Message-ID: <Z4Oi9.36756$>

"Nathan Allan" <> wrote in message
> "mountain man" <> wrote in message
> > 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.

The environment which houses the database application software. Normally located on the distributed client desktop or one or more application servers.

Precision, as you point out, is everything. To this end I have attempted to outline this argument on the following page:

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

At that time, they may well have.

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

Point taken here, with the encryption facility. However when the full nature of such commercial products is examined in detail my questions would have to be these:

  1. How many lines of code exist external to the RDBMS?
  2. How many lines of code exist internal to the RDBMS?
  3. What is the function of the code external to the DB?

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

Just because we do not seem to have an RDBMS vendor who has answered all the above such matters in today's world, should I who seek such a solution say to myself:

"Perhaps I will return to the shop tomorrow, and see whether such a perfect system, that will have no problems at all, will be ready. If it is, then I will buy it. But if it is not, then I will wait until it is ready"

Can you imagine the problems of this approach? Yet it seems you support it.

All the problems that people have thrown up in this newsgroup and others, and in the planet's stock of comments concerning RDBMS software are resolvable in production with workarounds.

Some folk need to run the RDBMS software to manage their organisation and they take all the above list of problems on board with them. And they are aware of these problems. And they work around each and every one of them.

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

The front end of the application which is fully defined within the RDBMS is a portal to the RDBMS. One small light-footed program with absolutely zero application specific code. Consequently, it requires zero maintenance when developing using it, because all such development, by implicit design, is achieved exclusively by harnessing RDBMS stored procedures.

Through this portal, all organisational users have the application presented to them.

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

As often as you run the check. You want to run the check every 2.7 seconds, then you can trust it at the end of every 2.7 second interval during the business day.

Let me ask you a question about a production system, and not a hypothetical theoritical analytical machine sitting on the drawing board for future release ....

You and others have asked this question: "How often can you trust your data?"

Now I ask you ... provide an alternative approach to have this question answered in realtime, (re: a production RDBMS) now, today. ;-)


> -Arbitrary nature of which constraints are enforced where...
> -Imperative nature of procedure based constraint enforcement
> encourages bugs, degrades performance, reduces optimizability.

Ditto --- see above.

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

Nathan, this is not even a big IF.
It is a non-existent IF at them moment.
And I am used to working in production.

I do not have the time to consider something that does not exist. Of course, it would be wonderful if, in the evolution of the RDBMS such facilities could be evolved.

And yes, as such facilities appear we can certain cancel and relax the corresponding data integrity exception checking. But until they appear, what is there to be done? My response is an EMS.

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

You have no argument from me, IF IT CAN BE DONE.

My point is simply:
it is not done yet.

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

This indeed would be a service that the RDBMS vendors could introduce in the absence of all those other features and database services you reference above.

I have constructed my own automated integrity checking, and I believe all production sites need an automated EMS.

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

This EMS product is but a specific instance of an application. It is something I can do at a production site using some RDBMS product X. I do not have the means to change product X, so I have to work around its shortcomings.

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

While that may be so, in examination of the actual code and modules which comprise this software you must admit that you would be able to separate those threads which deal with specific transactions within each of the above layers.

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

See above. The user interface will be one small light-footed RDBMS portal software program.

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

There is a diagram on the page earlier provided which shows that in the arrangement there is a "box" opposite the RDBMS server on the client stack --- intentionally left blank.

The entire 3rd environment can go providing the RDBMS portal software is able to be seen as the occupant of that box. If not, then envisage an application software environment where the number of separate executable programs is one, not many, and the entire (db) apps environment is one program - the portal.

> > 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!" ;-)

Ha hA! ;-)

There could be some truth in this as well. But in the long run the users are the most important elements in the equation.

My proposal is to give each user only one program in order to perform IO with the RDBMS rather than a suite of three thousand (eg) executables (each on their desktop or clustered on an apps server).

It is an approach of simplification by internalisation. The applications get moved inside the RDBMS and are referenced by an RDBMS client portal software.

Thanks for the thoughtful dialogue.

Best wishes,

Farmer Brown
Falls Creek, OZ
Received on Fri Sep 20 2002 - 18:46:18 CDT

Original text of this message