As part of the blog series TSQL - Solve it YOUR Way, I will present a topic recently discussed in the Transact-SQL MSDN forum here, followed by three different solutions to this problem supplied by three of the most active and helpful contributors in the forums, Tom Cooper, Naomi Nosonovsky, and Kent Waldrop. More importantly, they have included thoughts as to how they arrived at each solution. By seeing the different solutions along with a glimpse into their thought process, you can compare the different approaches to the solutions and learn from each of them.
Topic: I am writing a Text to Speech application and want to parse integer values into digits and convert them into the text representation of each digit. Example: Convert 16498 into the string "one six four nine eight".
Solution #1: Provided by Tom Cooper
The reason that I picked this solution is it is simple and easy to understand. That means it is easy to maintain. Maintainability is a very important consideration when developing software. So, for example, let's consider sometime in the future that this problem is extended to include the requirement that the number may have embedded commas, and/or the number may be preceded by a minus sign (-). If the requirement is to remove the comma’s and change the minus sign to the word “Minus”, then you could give this to a junior programmer who could easily understand this code and make the updates. Note, I have changed this slightly from my original answer. I have made the second argument to each REPLACE function call a string constant, not an integer constant. Either way works, but, of course, since REPLACE wants a string there, it is better to give it as a string rather than relying on the implicit conversion that will take place.
Solution #2: Provided by Naomi Nosonsovsky
I first created a table that contains the mapping/conversion (ex: 1:one, 2:two, etc). Then using the numbers table, I parse the original value into individual digits using common table expressions (CTE's), join that with the conversion/lookup table, and then finally concatenate back using the XML PATH approach in the final @Output parameter.
Solution #3 - Provided by Kent Waldrop
I used the APPLY operators because it is a method of clarifying the code with which I am comfortable. Frequently, I will initially build a query in-line and then push complexity down into APPLY operators. This is a design alternative to use of CTEs or derived tables. However, if I am working with either Oracle or DB2 I tend toward the CTEs because the APPLY operator does not exist for either of these dialects. Notice how well the CROSS APPLY partitions the calculations into more easily understandable portions. Of course the same thing could be done with CTEs or derived tables.
There are a number of bookend operations that can be used for conditional processing. The most widely used combination is the CASE structure. Other potentials bookends include the use of NULLIF and COALESCE, the SIGN function and the IIF function if you using SQL Server 2012. In this case I chose to use the NULLIF and COALESCE bookends for conditional processing – but why?
Look again at the structure of the code. Notice that the COALESCE function is in the SELECT clause and that the NULLIF is in one of the CROSS APPLY clauses. By using these two operations to bookend my conditional code I can divide my code across a big boundary like this in order to reveal each distinct portion of the code.
As you can see, all three of the above solutions provide the result we were looking for, but do so in a very different style. The original thread provides variations of the solutions presented here as well as one additional solution using a CASE statement. Each of these solutions leverages different SQL Server language constructs and includes different considerations in the final solutions. I hope that you are able to learn a lot by trying out the problem yourself and then reading through the additional solutions.
Special thanks to Tom, Naomi, and Kent for their valuable forums contribution and for contributing to this series!
Hope that helps,
Sam Lester (MSFT)
Tom Cooper began his programming career in 1968, began working with database software in 1977, and first worked with Microsoft SQL Server in 1994 (version 4.21). He is now very happily retired.
Naomi Nosonovsky, Senior Software Developer, has more than 15 years of enterprise experience in analysis, design, development and implementation of high-performance client/server data management solutions. She is a Personality of the Year for 2008, 2009, 2010 and 2011 at www.universalthread.com in .NET, SQL Server & VFP categories. She is also an All Star contributor/MCC Community Contributor at forums.asp.net and MSDN T-SQL forum. She also actively blogs at http://blogs.lessthandot.com/index.php/All/?disp=authdir&author=218 and http://beyondrelational.com/members/naomi/modules/2/posts.aspx?Tab=16.
Kent Waldrop started working with Sybase Transact SQL in 1989 as an application developer and continued working with Sybase until 1995 when SQL Server 6 came out. At that time, he became a Microsoft SQL Server database administrator and has continued to work with Microsoft SQL Server ever since. Currently he is a database architect working with Microsoft SQL Server, Oracle and UDB/DB2.