SQL Server Team-based Development - Red Gate Software

SELECT UserId ,
UserName ,
UserPassword ,
UserStatus
FROM Users
WHERE UserStatus IN ( 'Inactive', 'Deleted' )
GO
Listing 11-18: The "Tell, don't ask" anti-pattern.
345
Chapter 11: SQL Refactoring
Notice anything particularly wrong with this code? No? I didn't either, for a long time.
However, the issue here is that we're using the actual UserStatus column values
(inactive, deleted, etc.) in the code, to filter rows. We compare the column value
to a scalar value, in the query, in order to decide whether a row meets the comparison
condition. In effect, we're asking instead of telling.
The problem with this approach only becomes apparent when one considers what
would happen if, for some reason, we had to change one of the UserStatus strings, for
example, changing the UserStatus from Deleted to Removed. This will essentially
change the number of rows this query will return. To fix that, we'd have to change our
code everywhere we referenced that string. Furthermore, what happens if a customer
wants to execute some defined action for all users that are Inactive and Sleeping, or
Active and Sleeping? Some developers might try to solve this with enums, but this
doesn't give us a clear data meaning from the data itself; we need to decode the enum in
order for the data to make sense.
The real answer is to "Tell, don't ask." We need a column that describes the condition,
and then in the code, just evaluates this condition to true or false. This is a DDL
refactoring problem, i.e. this refactoring involves making a change to the table schema.
By changing the conditions in code to actual columns in the table, the intent of the
condition is clearly understandable and maintainable. Listing 11-19 shows the refactored
DDL and the fixed query.