T-SQL: Simplified CASE expression

Current Revision posted to TechNet Articles by Saeid Hasani on 6/10/2014 11:16:31 PM

The goal of this article is providing explanations about using CASE expression and its alternatives which introduced in SQL Server 2012. This article is completely compatible with SQL Server 2012 and 2014.

Introduction

SQL Server 2012 introduces these two new functions which simplify CASE expression:

• Conditional function ( IIF)
• Selection function ( CHOOSE )

We also have been working with COALESCE, an old simplified CASE expression statement as a NULL-related statement since early versions. Although ISNULL is a function, which logically simplifies a CASE expression, but it never translates to a CASE expression behind the scene (by execution plan). By the way, we will also cover ISNULL in this article, as it is an alternative to COALESCE. The goal of this article is providing in depth tutorial about these statements:

1. ISNULL
2. COALESCE
3. IIF
4. CHOOSE

I prefer using the term “statement” because although they do similar job, but they are not in same category by their purpose. For example, ISNULL is a function while COALESCE is an expression.

As we will see later, the main purpose of introducing these statements is improving code readability and achieving cleaner code. Using these statements may result to poor performancein some situations. Therefore, we also will discuss alternative solutions.

This article targets all levels of readers: from newbies to advanced. So, if you are familiar with these statements, you may prefer skipping Definition section.

Definition

ISNULL

If expr_1 is null, then ISNULL function returns expr_2, otherwise returns expr_1. Following example shows its functionality.

Output:

When the data types of two arguments are different, if they areimplicitly convertible, SQL Server converts one to the other, otherwise returns an error. Executing follow code results an error as illustrated in output figure.

Output:

Changing value of variable @Val_2 to ‘500’, we do not encounter any error. Because this value is convertible to numeric data type INT. Following code shows this:  

Pic 003

Implicit conversion may lead to data truncation. This will happen if the length of expr_1 data typeis shorter than length of expr_2 data type. So it is better to convert explicitly if needed. In the next example first output column suffers from value truncation while second will not.

Output

Determine output data type

There are few rules to determine output column's data type generated via ISNULL. The next code illustrates these rules:

Output:

Determine output NULL-ability

Follow code illustrates the rules to determine output column data type generated via ISNULL:

Output

COALESCE 

COALESCE returns the first NOT NULL expression in the expression list. It needs at least two expressions.

Dissimilar from ISNULL function, COALESCE is not a function, rather it’s an expression. COALESCE always translates to CASE expression. For example,

COALESCE (expr_1, expr_2)

is equivalent to:

CASE

WHEN (expr_1 IS NOT NULL) THEN (expr_1)

ELSE (expr_2)

END

Therefore the database engine handles it like handling a CASE expression. So this is inside our simplified CASE expression list.

Following code is one of many samples that could illustrate different execution plans for COALESCE and ISNULL:

Pic 007

By using COALESCE, we do not have the limitations that discussed about ISNULL function, neither about output column data type nor output column NULL-ability. Even there is no more suffering from value truncation. The next example is the new revision of the ISNULL section examples, but replacing with COALESCE:

Output

IIF

IIF is a logical function which was introduced in SQL Server 2012. It is like conditional operator in C-Sharp language. When condition is true, x evaluated, else y evaluated. Following example illustrates this function usage.

Like COALESCE expression, IIF function always translates to CASE expression. For instance,

IIF ( condition, true_value, false_value )

is equivalent to:

Case

when  (condition is true) then (true_value)

Else (false_value)

End

This example shows that this translation.

Pic 010

CHOOSE
 

CHOOSE is a selection function which was introduced in SQL Server 2012. It’s like switch operator in C-Sharp language. If index (must be convertible to data type INT) is NULL or its value is not found, the output will be NULL. This function needs at least two arguments, one for index and other for value. Following code illustrates this function usage.

Like COALESCE expression and IIF function, CHOOSE also always translates to CASE expression. For example,

CHOOSE ( index, val_1, val_2 )

is equivalent to:

Case

when  (index = 1) then val_1

when  (index = 2) then val_2

Else NULL

End

This simple code shows that this translation.

Pic 012

Performance

Although the main purpose of simplified CASE expression statements is increasing readability and having cleaner codes, but one important question is how these statements impact on the database performance. Is there any performance difference between CASE expression and these statements? By the way, to achieve best performance it’s usually better to find alternative solutions and avoid using CASE and these statements.

Dynamic filtering

This is common to write reports which accept input parameters. To achieve better performance it’s a good practice to write their code within stored procedures, because procedures store the way of their executing as an execution plan and reuse it again. By the way, there are some popular solutions to write this type of procedures.

IS NULL and OR

This is the most common solution. Let me start with an example and rewrite it with comparable solutions:

Execution statistics:

The main problem here, as illustrated in above figure, is using same execution plan for all the three situations. It’s obvious that the third one suffers from an inefficient execution plan.

CASE

We can change the combination of IS NULL and OR and translate it using CASE. Now we rewrite above code like this one:

Execution statistics:

Using CASE shows improvements to IS NULL and OR, but with more CPU cost for the first one. Also the Reads and Actual Rows decreased in first two executions. So it’s better but still we continue our experiment.

COALESCE

We also can change CASE and translate it to COALESCE. Now we rewrite above code like this:

Execution statistics:

It’s obvious that because COALESCE translates to CASE internally, so there is no difference between them.

ISNULL

Now we rewrite above code and use ISNULL instead of COALESCE:

Execution statistics:

There is no change in Duration, but with more estimated rows.

Dynamic SQL

Using above four solutions we could not achieve good performance, because we need different efficient execution plan for each combination of input parameters. So it’s time to use an alternative solution to overcome this problem.

Execution statistics:

There is no doubt that this solution is the best one! Here is the comparison chart. (lower is better)

 

You can find more information about last solution inErland Sommarskog website.

Concatenate values in one column

This is another common problem that fits our discussion. In this example we just cover COALESCE and ISNULL solutions and at last we will see an alternative solution which performs better than using the CASE solutions.

COALESCE

Next code concatenates the values of column “ProductID” and delimites each with comma separator.

Execution statistics:

This code executed in 13 seconds in our test system.

ISNULL

Now we rewrite above code and use ISNULL instead of COALESCE:

Execution statistics: 
                                                                       

The duration decreased to 3 seconds.

XML

It’s time to use alternative solution to overcome this problem.

Pic 020

The duration decreased to 21 milliseconds. Here is the comparison chart. (lower is better)
Note that XML runs at lowest duration.

There is no doubt that this solution is the best one. But because using XML, this solution has some limitations related to XML reserved characters like "<" or ">".  

Branch program execution based on switch between possible values

This is so common to use CHOOSE function to write cleaner codes. But is it the best solution to achieve optimal performance? In this section we will discuss about this question.

CHOOSE

Let’s start with an example that uses CHOOSE as its solution.

Execution statistics:

This code executed in 352 milliseconds in our test system.

UDF function

Now we rewrite above code and use a Table Valued Function to produce CHOOSE list:

Execution statistics:   
                                                                     

The duration decreased to 195 milliseconds.

Permanent Lookup Table

It’s time to use alternative solution to overcome this problem.

Execution statistics:

The duration decreased to 173 milliseconds. Next figure shows the comparison chart between these solutions. (lower is better)

This solution is the best one. By increasing the number of values in parameter list of CHOOSE function, the performance decreases. So by using permanent look-up table that benefits from physical index we can achieve the best performance.

More Readability

The most important goal to use these simplified CASE statements is achieve cleaner code. Many times we encounter this issue that code is so large that the SELECT list becomes more than hundred lines of code. Therefore there is a significant reason to use these statements. I was faced a simple problem just few years ago. In first sight it seems that solution should be very simple. But after writing the code using CASE, I found that I am in trouble. The problem was so simple. Assume that a department store has two discount plan, one based on purchases amount, and other based on the distance from customer’s home to store. But the rule was that just one plan that is greater is applicable. Next code shows two solutions, first by using CASE and second uses IIF. 

As illustrate in above code, IIF solution is more readable.

Conclusion

Using simplified CASE expression statements results to have cleaner code and speed up development time, but they show poor performance in some situations. So if we are in performance tuning phase of software development, it’s better to think about alternative solutions. 

---

See Also 

• Transact-SQL Portal

---