front-end vs back-end

client-server, RPC, stored procedures, triggers, integrity, rules

I think that employing triggers and stored procedures at the server side brings along a number of benefits, inter alia:

1) independence from front-end idiosyncrasies
2) data integrity is preserved, if triggers are well designed, which implies encapsulating business rules inside triggers, which are triggered regardless of front-end tool employed, incuding sqlplus, etc.
3) network traffic is drastically reduced, as an RPC is simulated without passing all the primitives across the network for parsing, etc. Procedures, etc are pre-parsed and therefore will be quicker to execute.
4) invalidation of procedures (new version) is handled automatically.
5) use of shared-pool is optimised (one version of function is cached, instead of numbers of different SQL statements having same function coded by different developers
6) admin of procedures and triggers, especially using packages is reduced from a nightmare in the case of client-side code. Just think of 1000's of user stations out there having to receive new versions if a business rule should change!

Of course, the downside is that the user interface is differnt due to triggers firing after the db action (insert, delete..) is done, which involves the db with possible i/o while client side will not incur this cost, but there is always a price to pay.

Cheers,
Manny Otto Received on Fri Dec 09 1994 - 17:48:30 CET