Simplified CASE expression

Introduction

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

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

Also we have been working with COALESCE, an old simplified CASE expression statement as NULL related statement prior SQL Server 2012. 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, since it’s an alternative to COALESCE. The goal of this article is providing an in depth tutorial about these four statements:

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

I use the term “statement” because although they do similar duty 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 are improving code readability and simplifying maintenance of code. But in some situations these statements usage will lead to poor performance. So we also will discuss about some alternative solutions.

This article targets newbies to advanced audiences. So if you are familiar with these statements, you can skip definition section.

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

Pic 001
Image may be NSFW.
Clik here to view.

If the data types of two arguments are different, if they areimplicitly convertible SQL Server converts one to the other, otherwise returns an error. Next sample execution leads to an error as illustrated in output figure.

Pic 002
Image may be NSFW.
Clik here to view.

Whereas by changing the value of the variable @Val_2 to ‘500’, because this value is convertible to numeric data type INT, we do not encounter any error. Following code demonstrate this:  

Pic 003
Image may be NSFW.
Clik here to view.

Implicit conversion in ISNULL function also could lead to truncate value, if the length of expr_1 data typeis smaller than length of expr_2 data type. So it’s safer to convert explicitly if needed. In next example first SELECT list column suffers from value truncation while second will not.

Pic 004
Image may be NSFW.
Clik here to view.

The next code illustrates the rules to determine output data type:

Pic 005
Image may be NSFW.
Clik here to view.

The next code illustrates the rules to determine output data type:

Pic 006
Image may be NSFW.
Clik here to view.

COALESCE returns the first NOT NULL expr 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 CASE expression. So this is in our simplified CASE expression list.

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

Pic 007
Image may be NSFW.
Clik here to view.

By using COALESCE, we do not have the limitations that discussed about ISNULL function, neither about output data type nor output column NULL-ability. Even there is not suffering from value truncation. To illustrate these points, next example is the new revision of former examples that was provided for ISNULL, but replace with COALESCE:

Pic 008
Image may be NSFW.
Clik here to view.

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

Pic 009
Image may be NSFW.
Clik here to view.

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
Image may be NSFW.
Clik here to view.

CHOOSE
 

CHOOSE is a selection function which 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, output will be NULL. This function needs at least two arguments, one for index and other for value. Following code illustrates this:

Pic 011
Image may be NSFW.
Clik here to view.

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
Image may be NSFW.
Clik here to view.

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. Does any performance different between CASE expression and these statements? In this path we will be noticed that to achieve best performance it’s usually better to find alternative solutions to avoid using CASE and these statements.

This is common to write reports and searches 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 do this.

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

Pic 013
Image may be NSFW.
Clik here to view.

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

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

Pic 014
Image may be NSFW.
Clik here to view.

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

We can change CASE and translate it to COALESCE for conditions in WHERE clause. Now we rewrite above code like this:

Pic 015
Image may be NSFW.
Clik here to view.

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

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

Pic 016
Image may be NSFW.
Clik here to view.

There is no difference in Durations, but with more estimated rows.

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

Pic 017
Image may be NSFW.
Clik here to view.

There is no doubt that this solution is the best one!

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

This is another common problem that fits to 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.

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

Pic 018
Image may be NSFW.
Clik here to view.

This code executed in 13 seconds in our test system.

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

Pic 019 
Image may be NSFW.
Clik here to view.                                                                       

The duration decreased to 3 seconds.

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

Pic 020
Image may be NSFW.
Clik here to view.

The duration decreased to 21 milliseconds.

There is no doubt that this solution is the best one. But because using XML, this solution has some limitations related to some special characters.  

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 discuss about this question.

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

Pic 021
Image may be NSFW.
Clik here to view.

This code executed in 352 milliseconds in our test system.

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

Pic 022   
Image may be NSFW.
Clik here to view.                                                                     

The duration decreased to 195 milliseconds.

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

Pic 023
Image may be NSFW.
Clik here to view.

The duration decreased to 173 milliseconds.

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 lockup table that benefits from physical index we can achieve the best performance.

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. Therefore this is a significant reason to use these statements. I encountered simple problem just few years ago. In first sight it seems that solution should be very simple. After writing the code using CASE, I found I am in trouble. The problem was 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 it:

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