On previous Oracle projects I have encouraged keeping the intelligence in the database in stored procedures. On a former project 95% of the business logic was in the PL/SQL procs in the database and the 'presentation' tier (GUI) was Java applets. The Java code then made calls to the database stored procs passing paramaters. It worked very well.
There are four principle reasons for this.
1. SQL that is in stored procs is already parsed (~compiled) against the database thus when it is called it will run quicker than application code which wont be pre-parsed against the database.
2. If you need to implement an emergency fix a stored proc can be re-compiled within seconds as opposed to over night builds etcetera which can happen with applications.
3. The amount of network traffic between client and server is then reduced as small calls are made as opposed to large SQL chunks being passed to and fro.
4. Its server centric...this keeps clients 'thin' normally driving down the cost of ownership.
I am not a big fan of triggers...they are some what invisible and if you forget they are there and change some data then changes will occur elsewhere in the datamodel that you might not have counted on. I would always prefer a stored procedure which had to be purposely called. It less automatic but more controlled; a trade off worth making in my opinion.
In the end though it comes down to the nature of the system and what it demands.
Hope this is the sort of comment you wanted.
Meowsh
Main Topics
Browse All Topics





by: skandalamPosted on 1999-10-14 at 10:59:57ID: 2127411
Edited text of question.