SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Case statement


Case statement

Author
Message
sqlfriends
sqlfriends
Hall of Fame
Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

Group: General Forum Members
Points: 3889 Visits: 4025
I would like use case statement in select .for example, if rate =100, then 1, if it is null, then 1, and if it is <>100, it is 0,

how to write the select case statement in best way?

Thanks
Alan.B
Alan.B
SSCertifiable
SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)SSCertifiable (5.2K reputation)

Group: General Forum Members
Points: 5231 Visits: 7732
This would do the trick:

SELECT
CASE
WHEN ISNULL(rate,100)=100 THEN 1
ELSE 0
END AS Rate
FROM {yourtable}



-- Alan Burstein



Best practices for getting help on SQLServerCentral
Need to split a string? Try DelimitedSplit8K or DelimitedSplit8K_LEAD (SQL 2012+)
Need a pattern-based splitter? Try PatternSplitCM
Need to remove or replace those unwanted characters? Try PatExclude8K and PatReplace8K.

"I can't stress enough the importance of switching from a 'sequential files' mindset to 'set-based' thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code. " -- Itzek Ben-Gan 2001
Steven Willis
Steven Willis
SSC Eights!
SSC Eights! (841 reputation)SSC Eights! (841 reputation)SSC Eights! (841 reputation)SSC Eights! (841 reputation)SSC Eights! (841 reputation)SSC Eights! (841 reputation)SSC Eights! (841 reputation)SSC Eights! (841 reputation)

Group: General Forum Members
Points: 841 Visits: 1721
sqlfriends (7/24/2013)
I would like use case statement in select .for example, if rate =100, then 1, if it is null, then 1, and if it is <>100, it is 0,

how to write the select case statement in best way?

Thanks




SELECT
(CASE
WHEN rate IS NULL THEN 1
WHEN rate = 100 THEN 1
WHEN rate <> 100 THEN 0
END)
AS RateCode



sqlfriends
sqlfriends
Hall of Fame
Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)Hall of Fame (3.9K reputation)

Group: General Forum Members
Points: 3889 Visits: 4025
Thanks both of you
dwain.c
dwain.c
SSCertifiable
SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)

Group: General Forum Members
Points: 7395 Visits: 6431
Why use a CASE at all?


WITH Rates (rate) AS (
SELECT -100 UNION ALL SELECT NULL UNION ALL SELECT 0
UNION ALL SELECT 100 UNION ALL SELECT 5)
SELECT rate, 1-ABS(SIGN(100-ISNULL(rate,100)))
FROM Rates





My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)SSC Guru (87K reputation)

Group: General Forum Members
Points: 87298 Visits: 41113
dwain.c (7/24/2013)
Why use a CASE at all?


WITH Rates (rate) AS (
SELECT -100 UNION ALL SELECT NULL UNION ALL SELECT 0
UNION ALL SELECT 100 UNION ALL SELECT 5)
SELECT rate, 1-ABS(SIGN(100-ISNULL(rate,100)))
FROM Rates




Just one reason but not the reason most who know me might think. On a million rows, the CASE method takes about 187ms (after optimizing for the "most common first" order , 234ms un-optimized) and the FORMULA comes in at about 218ms. While that's about 1/6th slower than the optimized CASE method, that's not the reason why I'd say to use the CASE statement. I say it's simply because the CASE statement will be easier to maintain by an individual not having quite as much formula knowledge. If the formula were MUCH faster across the million rows then, of course, I'd go with the formula and a comment explaining how it worked.

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
dwain.c
dwain.c
SSCertifiable
SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)SSCertifiable (7.4K reputation)

Group: General Forum Members
Points: 7395 Visits: 6431
Jeff Moden (7/26/2013)
dwain.c (7/24/2013)
Why use a CASE at all?


WITH Rates (rate) AS (
SELECT -100 UNION ALL SELECT NULL UNION ALL SELECT 0
UNION ALL SELECT 100 UNION ALL SELECT 5)
SELECT rate, 1-ABS(SIGN(100-ISNULL(rate,100)))
FROM Rates




Just one reason but not the reason most who know me might think. On a million rows, the CASE method takes about 187ms (after optimizing for the "most common first" order , 234ms un-optimized) and the FORMULA comes in at about 218ms. While that's about 1/6th slower than the optimized CASE method, that's not the reason why I'd say to use the CASE statement. I say it's simply because the CASE statement will be easier to maintain by an individual not having quite as much formula knowledge. If the formula were MUCH faster across the million rows then, of course, I'd go with the formula and a comment explaining how it worked.


Buzz-kill! :-D

But you're right of course.


My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
My temporal SQL musings: Calendar Tables, an Easter SQL, Time Slots and Self-maintaining, Contiguous Effective Dates in Temporal Tables
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search