Re: Business-logic in 3-tier architecture

On Sun, 13 Oct 2002 10:35:20 +1000, "mountain man" <prfbrown_at_magna.com.au> wrote:

>> All business logic should be in the logical DBMS.
>
>
>If the client application is about business logic (a more general term
>might be organisational intelligence) then not only should this logic
>reside internal to the (R)DBMS, but so should the entire client
>application environment (otherwise why have it? apart from those
>who need some specific form of pretty presentation layer?)

Well, all business logic should be in the logical DBMS, but for technical reasons you migth be interested in having some business logic replicated into the client.

If the process of business logic replication is automatic, much better.

>This is possible to do today.

Sure, I am also doing it :-)

>> Sadly, in a lot of cases the logical DBMS is not a relational DBMS.
>
>That's another problem entirely and irrespective of outcome
>came be resolved by any number of workarounds that have
>been engineered by fold trying to run such machines and data
>base structures over the last few decades.

I am lost here.

What I meant is that in many cases the logical architecture of 3 tier system is:

client application<--->pre relational dbms(application server)

And it is not a good idea.

>
>> In the worst cases the logical DBMS is a specific purpose object
>> (network) DBMS that uses an SQL-DBMS behind the scenes as a physical
>> storage system.
>
>In the best cases you have the (R)DBMS not only fulfilling the role
>as the database engine, but also competently configured such that it
>can store the organisational intelligence in totality.

Yes.

 In a nutshell: if you use a middleware, the middleware should be a relational DBMS and should have a relational interface.

>Application development occurs entirely within the
>(R)DBMS environment using stored procedures.

It is not necessarily true. Stored procedures may be avoided using a declarative language.

Alfredo Received on Sun Oct 13 2002 - 02:49:08 CEST