Re: Business-logic in 3-tier architecture

"Alfredo Novoa" <alfredo_at_nospam_ncs.es> wrote in message news:3da88466.510794_at_news.wanadoo.es... [...]
> With a relational DBMS triggers are not needed because you can enforce
> all business logic declaratively in a much better way.

Alfredo,
I agree with most of the things you mentioned. I think my question must be unclear or something.

Here's the point I'm trying to drive at: 1) Middleware (such as EJB, .NET, CORBA is where most current proposals are pointing to when it comes to putting business logic. 2) In my mind, that comes into direct conflict with the established ideas that business logic should be placed in storec procedures and triggers (if need be).

There are pros/cons in using any of them. Here's what comes to mind: a) Putting business logic into the DBMS seems to lock the application into a DBMS vendor
b) Putting business logic into the DBMS seems to lock the application into a middleware technology
c) Putting business logic into the DBMS seems to lock the application into a middleware may affect performance since the middleware may be further away from the data than stored-procs/triggers.

So, what kind of guidelines do you guys know that can help to decide what business logic is supposed to be in the middleware and others in the DBMS? Received on Mon Oct 14 2002 - 18:30:33 CEST