Re: And another one about PL/SQL

I use a mix of triggers and packages for handling business rules. We also use a combination of triggers and packages for working around the table mutation problem.

I don't disagree with most of what you say, but if you don't want 3 triggers per table you can use:

create or replace test_table_rbiud

    before insert or update or delete on test_table     for each row
declare
begin

• common code for insert/update/delete

    if (inserting) then

• insert code elseif (updating) then
• update code elseif (deleting) then
• delete code end if; end; / show errors; alter trigger test_table_rbiud compile;

"Rauf Sarwar" <rsarwar_at_ifsna.com> wrote in message news:c2d690f2.0206200935.71963dc7_at_posting.google.com...
> 1) Object management. Imagine having atleast 3 triggers (Insert,
> Update and Delete) on each of the 2000 tables will give me a
> nightmarish 6000 triggers to deal with. On the other hand, if I
> control the data integrity and enfore business rules through Packages,
> I will only need to have one package per table. Much cleaner and easy
> to maintain.
>
> 2) Tight Access. I like to control access to my database through
> Packages. No access to base tables. Only client access is through
> Packages and Views. Even if somebody accesses the table from Sql*Plus
> or MS Access etc...they cannot do anything to the tables unless they
> have execute privilges on the Package controlling the table.
>
> 3) Data Integrity. When a Package that controls the table is Invalid
> or dropped, user will get a hard error the moment they try to access
> it. However, when a trigger goes dead for some reason or you forgot to
> enable the trigger after some maintenance, user or yourself will not
> know about it until much later when the damage has already been done.
>
> Now these are purely my views...I am sure someone else will have pros
> and cons against using Packages but judging from above three
> situations...I much rather use Packages.
>
> Anyone care to dispute this :)
>
> Hope this clarifies it.
> //RS
Received on Sat Jun 29 2002 - 00:02:17 CDT