SQL Server Team-based Development - Red Gate Software

331
Chapter 11: SQL Refactoring
short, let this anti-pattern serve as a reminder never to put business logic inside your
stored procedures, unless you really, really know what you're doing.
The "one subquery per condition" anti-pattern
This is a very common anti-pattern in reporting queries where the requirement is to
perform aggregations based on certain conditions, for example: "return the count and
sum for each product in the table, based on condition1, condition2, and so on."
The trap that many developers fall into is assuming that the only way to apply the
conditions is in the WHERE clause. Since you can only have one WHERE clause per SQL
statement, the solution many developers reach is to have a subquery for each separate
condition. I can't really blame them, as it seems a logical conclusion to reach.
To demonstrate, let's first create and populate a test table, as shown in Listing 11-9.
IF OBJECT_ID('#TestTable') IS NOT NULL
DROP TABLE #TestTable
/*
Create a simple test table with names we'll group on and some random data
*/
SELECT TOP 100000
t1.name ,
– – get random numbers
ABS(CONVERT(INT, CONVERT(VARBINARY(50),
NEWID())) / 100000000) AS number ,
t1.type
INTO #TestTable
FROM master..spt_values t1
CROSS JOIN master..spt_values t2
GO
Listing 11-9: Creating and populating our test table.