In this chapter, you learned about a number of formatting and
coding conventions that can help you churn out better Transact-SQL.
Many of these apply regardless of whether you're creating a stored
procedure or some other type of SQL Server-
The harder it is to see the design in the code, the harder it is to preserve it.
Martin Fowler 
 Fowler, Martin. Refactoring:Improving the Design of Existing Code . Reading, MA:Addison-Wesley, 1999. Page 55.
In their book,
, Erich Gamma and company
(commonly known as the "Gang of Four" or GoF) propose that there
are certain patterns in software design that expert developers
regularly use and recognize in code written by others.
The Practice of Programming
espouses a similar
philosophy. In it, author Brian Kernighan proposes that programming
 Kernighan, Brian. The Practice of Programming . Reading, MA:Addison-Wesley, 1999. Page 11.
Although both of these books discuss software design from the
standpoint of object-oriented programming (OOP) languages, I have
long believed that common design patterns and idioms also exist in
query languages such as Transact-SQL. Expert developers regularly
use certain common techniques to build the code they write. The
purpose of this chapter is to catalog a few of these and to help
jumpstart a discussion of Transact-SQL design patterns and idioms.
For succinctness, idioms and design patterns are discussed
together. Just keep in mind that, although closely
the law of parsimony
In his book
Refactoring: Improving the Design of Existing
, Martin Fowler had this to say on the subject: "You build
the simplest thing that can possibly work."
with this statement to a point. A concern I have is that one man's
simple is another man's complex. Sizing up the complexity of a
proposed solution can be a completely
 Fowler, Martin. Refactoring:Improving the Design of Existing Code . Reading, MA:Addison-Wesley, 1999. Page 68.
You'll see the law of parsimony in evidence in many of the
idioms and design patterns covered in this chapter. One of the most
productive things you can do to write better code and to clean up
existing code is to remove unnecessary complexity. Doing so helps
you not just now, but six months from now when you or someone else
must work on the code again. It is an investment in the future
health of your code. If a loop to execute a block of code a given
number of times runs forward in some places and backward in
othersfor no apparent reasonthe code contains needless complexity.
People reading through it are forced to note that, even though the
code looks different, it actually
And, although there may be many ways to do something,