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.