Re: Business-logic in 3-tier architecture

"Alfredo Novoa" <alfredo_at_nospam_ncs.es> wrote in message news:3da88466.510794_at_news.wanadoo.es...
> On Wed, 09 Oct 2002 23:40:24 GMT, "Arthur Yeo" <ayeo_at_acm.org> wrote:
>
> >Theoretically, everyone knows that business logic is supposed to be in
the
> >middle-tier according to the 3-tier architecture. This seems to be
> >counter-intuitive to Active Database concepts such as putting business
logic
> >in triggers with help from store procedures in the DBMS (which are all in
> >the 3rd-tier of the 3-tier architecture.)
>
> The 3 tiers are at implementation level not at logical level.
>
> Logically there are still 2 tiers: client applications and the DBMS,
> but the logical DBMS has 2 physical tiers: the middleware and the
> SQL-DBMS.
>
> 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?)

This is possible to do today.

> With a relational DBMS triggers are not needed because you can enforce
> all business logic declaratively in a much better way.
>
> 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.

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

Remnant at the client application environmant is one small footprinted executable program which acts simply as a true (R)DBMS portal client, and requires no change.

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

In this manner, there no longer exists any client application software layer of environment WHATSOEVER. This is an excellent methodology for the alternate development and deployment of organisational intelligence threads, as the portal client enables this without effort.

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