Subject | A Tangle of Triggers & Stored Procedures: Best practices to unravel? |
---|---|
Author | mlq97 |
Post date | 2010-02-09T18:20:09Z |
I am having a real problem understanding & maintaining the interacting triggers and stored procedures in my DB. Because of poor coding I've got some serious performance problems which I need to fix but now I have accumulated so many nested things going on that I'm terrified to change anything in case it breaks or corrupts the business logic.
My code & logic is such a tangle that I can't understand it (& I wrote it!!). Often the problems are of the type where
Table A has an update trigger that updates Table B, which has an update trigger which updates table A etc. A nightmare to debug.
Is there a set of best practices for dealing with this problem by structuring triggers and sp's in an optimal way? For example is it better to:
*minimise the number of triggers by maximising the qty of code in each?
*maximise the number of triggers by minimising the qty of code in each?
*Use triggers mainly to call stored procedures?
Are there best preactices for trigger & SP naming conventions and trigger order etc?
I'd really appreciate any pointers to getting this mess unraveled.
Many thanks
Mitch
My code & logic is such a tangle that I can't understand it (& I wrote it!!). Often the problems are of the type where
Table A has an update trigger that updates Table B, which has an update trigger which updates table A etc. A nightmare to debug.
Is there a set of best practices for dealing with this problem by structuring triggers and sp's in an optimal way? For example is it better to:
*minimise the number of triggers by maximising the qty of code in each?
*maximise the number of triggers by minimising the qty of code in each?
*Use triggers mainly to call stored procedures?
Are there best preactices for trigger & SP naming conventions and trigger order etc?
I'd really appreciate any pointers to getting this mess unraveled.
Many thanks
Mitch