Re: theory and practice: ying and yang

"Paul" <paul_at_test.com> wrote in message news:42a06673$0$1706$ed2e19e4_at_ptn-nntp-reader04.plus.net...
> mountain man wrote:
>> My thesis is that if you take this migration to its logical
>> conclusion there may be achievable an optimal stage in which *all*
>> application software in internal to the DBMS in the form of stored
>> procedures.
>>
>> That is precisely what this tool does. It enables a service level
>> portal to the RDBMS for the user which is based solely on the
>> execution of stored procedures, and the ability to handle the
>> consequent sets of data being returned to the user.
>
> I think this may be confusing two separate advantages of having a
> centralised system. The first advantage is to be able to enforce data
> integrity constraints centrally. The second is to have managerial
> control over all parts of the system.
>
> Having business logic in the form of stored procedures offers no
> advantage (with respect to data integrity) over having the business
> logic held externally, if both are managed by the same person.

There is an advantage. In the traditional manner, with the logic held externally it is essentially being held in another software that is separate to the RDBMS software.

Examine the redundancies caused by definitions (especially of data schemas, and changes thereto) that are effectively held in two separate softwares. Each redundancy costs money, every single time it is visited. More costly though, and quite unseen, are the behind the scenes coordination exercises that are required to effectively manage changes to these two separate software locations.

The advantage in bring all code into the RDBMS is that your entire software environment is no longer a UNION of two different softwares, but in fact is now unified to one.

Application software may be created by scripting and be confined to a database file, right alongside the same data that it is manipulating.

> The advantage would come if the DBMS would somehow ensure the integrity
> of the stored procedures. For example, if you tried to drop a row from a
> table, it might refuse to let you if there existed stored procedures
> referencing that column. Or if you rename a column it might update all
> stored procedures that use it. Maybe some DBMSs do this kind of thing
> already; I'm not sure. But you've still got the problem of ensuring that
> the logic is semantically correct as well as syntactically.

Yes, but the semantics and syntax is now within one unified software environment. The task does not go away, but it does become a great deal easier to manage: one protocol is easier to deal with than two.

...[trim]...

> Here's a thought, building on your idea: design a client, maybe as an
> executable, or as HTML or somthing. Then store this in the database,
> either in a binary column or in some more structured way. Now you only
> have to give your users a minimal "bootstrapping" client that first
> downloads the "real" client from the database and runs it. Now you can
> have an arbitrarily complex client and it's all stored in the database!

A reasonable idea, but my idea of a client is a program that acts as the user interface to the RDBMS (for all data applications) and basically is a service level channel, saying "I know nothing, go and look in the database".

I use the same client for all industries, it does not change. It's just a portal
to services within the (R)DBMS.

Those services (nowdays) are sufficient
to represent the same code previously
stored in client code.

-- 
Pete Brown
IT Managers & Engineers
Falls Creek
Australia
www.mountainman.com.au/software