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

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

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

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

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

Pic 005

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

Pic 006

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

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

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

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 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

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

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

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

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

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

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

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

This code executed in 13 seconds in our test system.

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

Pic 019 
                                                                       

The duration decreased to 3 seconds.

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

Pic 020

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

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   
                                                                     

The duration decreased to 195 milliseconds.

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

Pic 023

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.