Re: The Practical Benefits of the Relational Model

"mountain man" <prfbrown_at_magna.com.au> wrote in message news:<Z4Oi9.36756$g9.105141_at_newsfeeds.bigpond.com>...

> At that time, they may well have.

We will have to agree to disagree, because frankly I think you give today's SQL DBMSs too much credit. They have added fluff here and there, but for the most part, they are the same sorry creatures. If you would like to experience this first hand, try building a general purpose relational DBMS that uses them "underneath." I don't know how many times I have sighed with frustration over some quirk we were forced to work around in these systems. And unlike application specific work arounds, general work arounds are not easy! <rant> All because someone decided it would be a good idea to prevent "case" statements from being nested more than 10 levels deep, or that only two levels of nesting are necessary within correlated sub queries in the "from" clause. </rant>

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

I think the point you are trying to make is clear: centralize the application logic. I think everybody agrees that this is a worthy endeavor. Accomplishing this without unreasonable compromise is another thing.

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

Let's look at where I am coming from. My company (Alphora) built a system that actually solves many of the raised issues and provides benefits such as those in my original posting. We are not complaining about the issues (well, maybe a little ;-), we have done something about them. I agree that waiting for a perfect solution will not get anyone far. That is why we did what we did. We wanted it. Nobody had it. So we built 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.

Certainly, but the more "around" the workarounds are, the longer projects take to build and maintain. What we have built can be looked at as a very elegant workaround because it "lives" with existing systems. But to the application developer it seems a lot more like a 1st class solution. :-)

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

Many people today take this approach. If the DBMS has the complete ability to enforce integrity, such procedures are not necessary. Development of data access procedures en mass is a time consuming, high maintenance, and limiting task. And those are the good attributes! :-)

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

Again, I think you underestimate the potential requirements on this "portal." Your purposed stored procedure solution is more evidence of this.

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

2.7 seconds or even continuous looping is not real-time. Transactions form the basis of time variance within a database, not an extenal clock or loop. There is a huge logical difference between the data being "usually good" and being "always good." I am not just being nit-picky. The user or system who is attempting modification should know that the data is bad. The data should never be allowed to be bad. C. J. Date: "Database design is really all about specifying integrity constraints! Database design is constraint definition."

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

Okay: (www.alphora.com) Version 1.0 has been out since June. 1.1 comes out soon.

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

See above... so am I. ;-)

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

And I am saying that there IS a solution to these things and it CAN be done it real time. In fact all of the goals you are aiming for are accomplished elegantly in Dataphor. For example, we have (and have had) Windows and Web UIs that are dynamically derived from the database. They require no data access stored procedures and are driven from the data model. Check it out... I think you will like it!

> You have no argument from me, IF IT CAN BE DONE.
>
> My point is simply:
> it is not done yet.

I would be very interested in your feedback about Dataphor.

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

We can do it... and we can still use those systems underneath.

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

The reason I harp on this point is because I think it blurs the picture. The ideal to me draws a THICK line between application developer concerns and the concerns of the system programmer/administrator. As is illustrated by the "portal" discussion, implementation layers don't really matter so long as they are maintained as part of the system. The implementation should be transparent to the application developer. The implementation can give or take layers, switch out subsystems, or be replaced altogether, so long as the application logic is not affected. The RM provides the conceptual foundation for this very line.

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

Again, we differ. As stated, it doesn't matter how many executables or layers there are, as long as they form one general implementation that can readily be brought to a specific state for the purpose of a specific application. The implementing systems will naturally become simpler as a byproduct of drawing this logical/physical line more clearly.

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

Fire up the Dataphor Windows or Web Client. ;-) I am not trying to push product (well, yes I am) but this is exactly what you are describing.

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

Yes, I think we have identified some of the same problems and have arrived at similar solutions. I hope you will download and take a look at what we have. I would be interested in hearing your thoughts.

Sincerely,

--
Nathan Allan