As I was working on several solutions to a database query, I sent an email to a friend that is an excellent DBA-Developer for help. He knows databases very well, both querying and administration, and can still code (a rare combination). At first I was trying to use a user-defined function (UDF) which abstracted out the logic of what I needed to do and all this other programmer-related buzzword stuff. He showed me two other ways to try, both using the set-based nature of SQL. Having had significant exposure to SQL development before, I had one of those "duh" moments.
Then it occurred to me that one of the problems many programmers have is adjusting to set-based thinking. With our heads down pounding out code, we get used to sequential thinking. Even object-oriented code, within each method or event, is sequential. You start at the beginning of the method, do this and that, and return some result. Sequentially-based thinking. Set-based thinking is often only encountered when a developer accesses a database. Considering the majority of actions are simple CRUD (Create, Read, Update, and Delete), many will never make the transition to set-based thinking because they get no exposure to it. This can often lead to performance-challenged solutions.
To prevent any of the intelligent readers of DotNetJunkies or my blog (all 2 of you!) from being unskilled and unaware of it, I went looking for some decent explanations from someone reputable. There is the book Joe Celko's SQL for Smarties (Amazon Associates link), which I highly recommend if you are going to develop serious database-backed applications. Itzik Ben-Gan, T-SQL Black Belt for SQL Server Magazine, constantly preaches finding a set-based solution. Select articles are Set Members and Relationships (first in a series), Sequential to Set-Based, and Matching Transactions.