CASE Statements Tutorial in SQL
DON'T MISS THIS ONE!! š¤Æ
Got BDE?ā”ļø
If you wanna support my newsletter and click rates, please CLICK A LINK somewhere in here ā¤ļø And subscribe on YouTube š„ā Just hit 7.5K subs š
And BIG announcement⦠Iām moving my courses to Kajabi to provide an even better user experience!! š„³ Iām also planning some big, BIG Black Friday deals! Reply to this email on what you wanna see š
If youāve been keeping up with the angry face emoji LORE from last week š, I have a new advancement for you LOL. Last weekās post prompted another angry email from a different person. Guess a lot of people are mad about this emoji: š”
CASE Statements: The Swiss Army Knife of SQL
Case is a serious SUPER POWER in SQL because it can help you categorize data, replace nulls, create binary columns, and even PIVOT data in SQL. Yes, like making a pivot table summarize your data! We donāt have time to learn alllll of this here, but head on over to my šintermediate course if you want to learn more on CASE and become an expert š CASE is one the biggest ROI SQL skills you can learn, so my intermediate course has a WHOLE chapter on them.
Case works like a fancy if then statement where you can define multiple conditions and it will output the result for the first condition met. Hereās the basic syntax:
case
when condition1 then output1
when condition2 then output2
...
when conditionN then outputN
end as column_nameBecause it steps through the conditions in order, ORDER MATTERS if your logic is dependent on the previous conditions. That means if youāre relying on waterfall logic and depending on and building off of the previous conditions above, you have to make sure your logic is super tight and there are no holes or unaccounted for edge cases. Itās really easy to accidentally forget an equals sign or mess up your numbers and produce incorrect results. See the query below where we rely on waterfall logic to classify revenue.
select
order_id,
price * quantity as rev,
case
when rev < 100 then āsmallā
when rev < 500 then āmedā
when rev < 1000 then ālargeā
else āextra largeā
end as rev_amount
from
orders
;If the first condition isnāt true, we go to the second. If the second condition isnāt true, we go to the third. And so on until a condition is true! For example, the second condition (classifying med) relies on the logic that the number is less than 500, and assumes itās also greater than or equal to 100 since the first condition was NOT met. And for the 3rd condition (classifying large) relies on the logic that the number is less than 1000, and assumes itās also greater than or equal to 500 since the first and second conditions were NOT met. This is what I mean by waterfall logic!
To emphasize my point further, see what happens when you switch the order of the conditions and put large on top. Does this change your output? It does, because itās no longer relying on the small and medium conditions since theyāre further down in the logic and CASE returns the FIRST met condition output. This produces INCORRECT results below and accidentally misclassifies all the small and medium values as LARGE:
select
order_id,
price * quantity as rev,
case
when rev < 1000 then ālargeā
when rev < 100 then āsmallā
when rev < 500 then āmedā
else āextra largeā
end as rev_amount
from
orders
; This is why order matters when you use dependent waterfall logic and why you have to be so careful when defining logic in CASE. If you want to write a query that does not rely on waterfall logic (and order doesnāt matter), you can clearly define the upper and lower endpoints of your value ranges. Just be careful with your equal signs here and donāt leave any holes in your logic. See the YouTube video š for an example of this!
Keep that BDE rolling š š¼
Jess Ramos š
ā”ļøIf youāre new here:
šš½āāļø Who Am I?
Iām Jess Ramos, the founder of Big Data Energy and the creator of the BEST SQL course and community: Big SQL Energyā”ļø. Check me out on socials: šYouTube, šLinkedIn, šInstagram, and šTikTok. And of course subscribe to my šnewsletter here for all my upcoming lessons and updatesā all for free!





The original proof only requires that when there are overlapping reads and write to the same storage, only the the write must be correct, for the algorithm to function properly.
And yes, it assumes that there is cache coherence among all actors, and therefore that the writes will be idempotent across all nodes ā which in fact is what guarantees coherency.
The algorithm was developed for cache coherent MESI coherence model systems, or better.
So no, it does not include clusters, or distributed systems, unless they also guarantee operational idempotence.
For databases in particular, including the subset of instances of database implementations we callāfilesystemsā, that the overall system provides ACI(F)D guarantees.
Databases which only supply BASE, like NoSQL implementations, need not apply.
Or in other words, donāt expect Lamportās to work on those systems, and pick a different algorithm instead,because in the context of the proof onthose systems, the proof no longer is a proof.