Re: The Practical Benefits of the Relational Model

From: mountain man <prfbrown_at_magna.com.au>
Date: Thu, 26 Sep 2002 15:30:48 +1000
Message-ID: <xHwk9.40090$g9.116097_at_newsfeeds.bigpond.com>


"Nathan Allan" <nathan_at_alphora.com> wrote in message news:fedf3d42.0209231609.4b04dd7f_at_posting.google.com...
> "mountain man" <prfbrown_at_magna.com.au> wrote in message
news:<Z4Oi9.36756$g9.105141_at_newsfeeds.bigpond.com>...

...[trim]...

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

The procedures of which I speak are not exception management procedures, but stored procedures which are responsible for returning data back to the organisational user. While I think I can see WHERE Alphora sits in the environment, I think you dont yet perceive what my company has created.

We have created an (R)DBMS portal client which enables the migration of code previously in the applications environment external to the (R)DBMS, into the (R)DBMS environment --- independent of the orgainsational type.

We have called the product LittleSteps.
http://www.mountainman.com.au/software/

It is an application development tool and an RDBMS Portal client (combined)

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

The development and maintenance of applications using LittleSteps consists of creating stored procedures ---- exclusively. An example application might be a multi-level drill down analysis display from summary to summary to detail to logged information, for example.

As both the code and the data always reside 100% within the (R)DBMS then the response time is always faster than the end results of any other application development method.

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

I will make some time next month and take a look at your product. Perhaps you could persevere and assist me in trying to better explain what my product actually is.

Best wishes for now,

--
Farmer Brown
Falls Creek, Australia
http://www.mountainman.com.au/software
Received on Thu Sep 26 2002 - 07:30:48 CEST

Original text of this message