Re: The Practical Benefits of the Relational Model

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

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

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

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.

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.

Regards
  Alfredo Received on Sat Sep 21 2002 - 14:38:43 CEST