I completely agree, Solomon... that's why I'm discussing the "con" side of this.

What I've found is that people will take some nice tools like you've developed and use them to make up for their lack of knowledge in areas like T-SQL and sometimes it just doesn't work out. For example, before I got there, the folks at work had 8 fairly wide tables (>100 columns). As if that weren't bad enough, they wanted to audit changes to an "EAV" style of audit table because the changes would usually only happen to a small handful of columns from any given table. Because they didn't want to write IF UPDATE() for every column in the trigger, they used a generic SQLCLR trigger on the tables... that would take nearly 4 minutes to audit changes to only 5 columns on a paltry 10,000 rows. The T-SQL replacements for those triggers work nearly instantaneously for 100,000 rows.

Now, I'm not saying that you've written "slow" code because I don't actually know and neither does the author because no one has done a performance test in this article. Yes, yes... I understand the grand utility of modular general purpose code. My general caution to people is to test any new thing they're going to add to their servers before they add it and that's my intent here because it really might not be worth the trade off in performance... or it might.

Like my ol friend Sergiy says, "A Developer must not guess. A Developer must KNOW!"

So, what say yea? How about some performance tests for those things that can also be done in T-SQL?