Re: The Practical Benefits of the Relational Model

"Alfredo Novoa" <alfredo_at_nospam_ncs.es> wrote in message news:3d8c66f4.5511264_at_news.wanadoo.es...
> On Fri, 20 Sep 2002 11:43:58 +1000, "mountain man"
> <prfbrown_at_magna.com.au> wrote:
>
> Hi
>
> >> > 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:
>
> Yes, but it is also far easier to manage one system software
> enviroment than two :-).

First steps first. ;-)

> >Not quite. It requires the presence of separately addressable
> >(from the apps environment) stored procedures within the (R)DBMS.
>
> Triggered procedures or stored procedures are very often needed due
> the poor declarative integrity capabilities of SQL DBMS's.
>
> With a 'D' language you can develop a complex business system without
> the use of any procedural code.
>
> >More importantly, it requires the software supplier to convert
> >all his/her code to the form of (R)DBMS stored procedures (ie: 100%).
>
> I think it would be better replacing the procedural code with the use
> of a declarative specification language.
>
> >and having all the source code visible to the end client DBA, etc.
>
> Not necesarily, I know systems where the stored procedure's source
> code was deleted after compilation.
>
> >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.
>
> And because the relational model was never implemented until now.
>
> >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.
>
> If you have a generic client application you will be faster deploying
> it because you don't have to develop anything.

While this may be quite true, at some stage the end client (whether that is an end organisation, or a developer) will need to develop -- in little steps -- an application.

At this end user development stage, the process of development for any one specific task is simply the creation of one or more stored procedures.

Deployment of this application to the end user is available as soon as the user re-examines the database (ie: it is automatic, and nothing is needed to be deployed into the client environment).

> >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).
>
> And why not the entire system with the portal?

Perhaps I was not clear. The portal is an integral part of the arrangement and exists as the user interface to the (R)DBMS.

In theory it is the one program object that replaces the hundreds or thousands of (application software) objects currently in the your standard environment 3.

Development of the application occurs within the (R)DBMS and requires zero client changes to this portal software. Therefore anyone who develops applications using this methodology need only develop stored procedures.

These of course are deliverable to the end organisational client after development in the form of a standard (R)DBMS database.

> In a lot of cases it is perfectly possible.
>
> >On face value, to me, it looks
> >just plain wrong. 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.
>
> But the data integrity is enforced using procedural code, and it is
> costly and error prone.

While you may have such a view of such practice, let me assure you that it is neither costly nor error prone when done properly. It is not costly simply because once the checks are established, automation kicks in and replicates the effect as long as the system runs for zero cost.

> And also you need to write stored procedures for all multitable views
> in order to make them updateable. With a real RDBMS all relations are
> updateable without aditional effort.
>
> >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
>
> DBMS's are just for this. If it is not very important what is
> important? :-)
>
> >1) 1st software system environment: Hardware OS and net OS
> >2) 2nd software system environment: (R)DBMS <<-------|
> >3) 3rd software system environment: (db) applications -->|
> >
> >Environments 1 and 2 and known stable reliable products
> >which may have as few as a dozen vendor combinations
> >covering more than 95% of all (R)DBMS sites.
>
> Enviroment 2 is very narrow. The only RDBMS I know is Dataphor. And it
> uses SQL DBMS's behind the scenes.

Environment 2 consists of DB2, Oracle, SQLServer and the host of other (R)DBMS software.

I have no problem with the role Dataphor is assuming in its endeavor to make RDBMS out of (R)DBMS.

Best wishes,

--
Farmer Brown
Falls Creek, OZ
http://www.mountainman.com.au/software