As for the article, I was expecting to see some insight on runtime performance using triggers vs SPs. For instance, from my own experience I found that using INSERTED from triggers takes a lot of time, and I assume that using SPs for the audit work would be better on performance. I've never had the time to do extensive research on this subject, and I guess I was expecting to see some in this article. pitty..
As far as the recommendations go, I must agree with noeld:
- From a programmer's perspective it seems to me that Part II would be better for maintenance in the long run (easier to mintain two simple objects than one compilated one).
- In the long run, even if we make sure to use SPs, YOU ALWAYS END UP WITH MORE THAN ONE SP PER TABLE ACTION! Fully-generic SPs never withstand the performance barrier, and you always end up making special SPs for special cases , thus having to maintain the audit logic in each SP turnes out to be a hassle and is prone to mistakes.
Either way, I was glad to see the article and it was interesting to read - learned alot about caching etc., which is always good to know.
- Avi