Lesson Description
Use CASE WHEN to translate raw values into business-ready categories and labels. This lesson helps you express decision logic directly in SQL for cleaner reports and clearer analysis.
Lesson Description
Use CASE WHEN to translate raw values into business-ready categories and labels. This lesson helps you express decision logic directly in SQL for cleaner reports and clearer analysis.
Easy Project
Mini project: Turn this lesson into a real-world query artifact by writing one clean business report query and validating output quality.
CASE WHEN evaluates conditions top-to-bottom and returns the result for the first match. It is SQL's if/else.
SELECT
first_name,
salary,
CASE
WHEN salary `<` 5000 THEN 'Junior'
WHEN salary `<` 10000 THEN 'Mid'
ELSE 'Senior'
END AS tier
FROM employees;
ELSE is optional. If omitted and no condition matches, the result is NULL.END closes the expression.SELECT
id,
CASE status
WHEN 'shipped' THEN 'On the way'
WHEN 'delivered' THEN 'Complete'
WHEN 'cancelled' THEN 'Cancelled'
ELSE 'Processing'
END AS status_label
FROM orders;
Control sort order programmatically:
ORDER BY
CASE status
WHEN 'cancelled' THEN 1
WHEN 'pending' THEN 2
ELSE 3
END
SELECT
COUNT(*) FILTER (WHERE salary `<` 5000) AS junior_count,
COUNT(*) FILTER (WHERE salary `>=` 5000
AND salary `<` 10000) AS mid_count,
COUNT(*) FILTER (WHERE salary `>=` 10000) AS senior_count
FROM employees;
(The FILTER approach is cleaner; CASE inside COUNT works too.)
SELECT, WHERE, ORDER BY, GROUP BY, and HAVING.FILTER or a lookup table for readability.This lesson is part of SQL Fundamentals. Focus on the core idea in CASE WHEN — conditional logic in SQL, then validate with deliberate practice.
What to master
Common mistakes
High-level strategy
Task ladder
Transparent data checks
Retention loop
Logical reasoning for commands
WHERE
Why: Limits rows to only the business-relevant subset.
Memory cue: Filter early to reduce noise.
ORDER BY
Why: Makes output deterministic and reviewable.
Memory cue: No ORDER BY means no guaranteed row order.
AS alias
Why: Makes output columns readable for teams and reports.
Memory cue: If the name is clear, the query is easier to trust.
Concept check
3 quick questions. One at a time. Instant score at the end.
Return first_name, last_name, salary, and a tier column: 'Junior' if salary < 5000, 'Mid' if salary < 10000, otherwise 'Senior'. Order by salary ascending.
No results yet
Run a query to see results here
From the store sandbox, return id (alias order_id) and a status_label column that maps: 'shipped' → 'On the way', 'delivered' → 'Complete', 'cancelled' → 'Cancelled', anything else → 'Processing'. Order by id.
No results yet
Run a query to see results here
From the hospital sandbox, return first_name, last_name, date_of_birth, and an age_group column: 'Born after 1990' if dob > 1990-01-01, 'Born 1960–1990' if dob > 1960-01-01, otherwise 'Born before 1960'. Order by date_of_birth DESC.
No results yet
Run a query to see results here
Final checkpoint
Pass mark: 80%. Review each explanation after you submit.
1. Which clause should you use to filter grouped results?
2. What is the safest way to avoid accidental row multiplication in joins?
3. Which feature is best for ranking rows within partitions?
4. Why should final analytical queries usually include ORDER BY?
5. When query logic gets complex, what improves readability most?