• You left out triggers...

    Good editorial. I agree with it. I also take, a very slight, exception to it. The problems that people who post here every day see are not that someone has a simple little cursor that does the job, quietly, efficiently or a table valued multi-statement function that really only returns about 10 rows so that it's generating a good execution plan that works well within the query, or a view that simply acts as a mask on table structures or builds out complex joins in a way that makes the rest of the code more maintainable. If this was what was primarily out there, then the good ole' saw "It Depends" would be all we'd need to define these issues.

    Instead we get cursors wrapped in cursors wrapped in cursors calling 15 million rows and why, oh why, does it run slow. We have multi-statement functions that return millions of rows and these frequently get called by other multi-statement functions also calling millions of rows and that "should be fine otherwise why does SQL Server let you do it." Etc.

    The reason so many people rail against the evils of these various tools isn't because there's anything wrong with the tools, but because they're so horribly misused so frequently. It just becomes easier to say NEVER use X rather than outline all the distinct times it's OK. So it really comes down to a bit laziness on the parts of posters who go that route, but that laziness is predicated on experience, not simply laziness.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning