Enhance performance by improving SQL coding practices.

Handing out blank checks in the world is definitely not a best practice if you're looking to avoid financial headaches and hardships. After a recent set of SQL performance engagements with clients, it's clear to me that a number of IBM i developers don't understand how to best check for blanks when using SQL with DB2 for i databases. As a result of these suboptimal coding practices, many developers are destined for performance and code maintenance headaches in the future.

This suboptimal SQL coding practice arises when a character column needs to be checked to determine if it contains all blank characters (also known as an empty string). Programmers believe that they have to help DB2 do this comparison instead of simply comparing the column to an empty string value with the following predicate: character_column = ''. This simple predicate is an SQL coding best practice whether the column is declared with a fixed-length or variable-length data type.

I think IBM i developers believe they must help DB2 with this comparison because the blank value being compared is a different length than the character column. Developers from other platforms are probably just propagating helper code that was necessary to deal with quirks in other database engines. In reality, the DB2 for i engine automatically adjusts for the lengths of the strings being different. Nevertheless, I've seen several developers "enhance" their SQL statements with the following types of predicates to "help" the DB2 engine determine whether a column contains all blanks:

• TRIM(TRAILING FROM character_column) = ''
• LENGTH(RTRIM(character_column)) = 0
• character_column = '                         '

All of these enhanced comparison predicates correctly detect whether a column contains all blanks, but these enhancements aren't necessary. Instead, these enhancements make your SQL statements longer and harder to read, which results in SQL code that's harder to support and maintain over time. More importantly, performance is actually slower with the first two enhancement techniques that utilize built-in SQL functions (TRIM, LENGTH, RTRIM).

These two enhanced comparison techniques are primarily slower because they rely on unnecessary calls to SQL built-in functions. In addition, the usage of a function on a column comparison typically prevents the DB2 query optimizer from using an index to more efficiently perform the comparison. Performance tests that I ran showed the predicate method that uses a combination of the LENGTH and RTRIM functions to be almost 15% slower than the best practice comparison predicate of character_column = ''. And this measurement doesn't even take into account the potential for a much more dramatic performance improvement when using an index as part of the comparison processing.

If you eliminate these predicate enhancements on one of your SQL requests, the performance difference is probably not going to be noticeable on a single execution of that SQL statement. Correcting an SQL statement that's run multiple times by multiple jobs, however, will noticeably impact the performance of your applications and system.

This coding technique and other SQL coding best practices for performance are covered in the DB2 for i SQL Performance Workshop.

In summary, the key to preventing headaches with SQL blank checks is to employ the KISS principle of "Keep it simple, stupid." Avoid the urge to enhance your blank comparisons and simply use, character_column='' instead.

Kent Milligan is a Senior Db2 for i Consultant in the IBM Lab Services Power Systems Delivery Practice.  Kent has over 25 years of experience as a Db2 for IBM i consultant and developer working out of the IBM Rochester lab. Prior to re-joining the DB2 for i Lab Services practice in 2020, Kent spent 5 years working on healthcare solutions powered by IBM Watson technologies. Kent is a sought-after speaker and author on Db2 for i & SQL topics.