So, we've employed a pretty elaborate scheme for getting around the Mutating table error, where we buffer rows in a PL/SQL table inside the BEFORE ROW trigger, and then process each of those rows in an AFTER STATEMENT trigger.
It works, but initial coding is usually strained by the fact that anytime you UPDATE, INSERT or DELETE from the AFTER STATEMENT trigger, you re-enter the BEFORE ROW trigger where the rows were buffered initially. So you have to write the appropriate control structures which circumvent the code specifically meant for the MUTATING TABLE error, but you still process your business rules.
So, I was thinking this morning, what if we moved this "MUTATING TABLE AVOIDANCE" code into an INSTEAD OF trigger, and updated via a VIEW. I goofed around with some code and it seems to work ok. So, I'm turning to ya'll now to see if there's some fatal, obvious flaw that I'm overlooking. I can't think of why it would be any different, other than the fact that you'd always need to perform DML via the view, whereas now you can go directly against the table.