Lesson 3 of 4

Progress: 0/3 exercises solved (0%)

← Previous

Solve all exercises below to unlock the next lesson.

Working with NULL

Lesson Description

NULL is "unknown" — comparisons need IS NULL.

Easy Project

Mini project: Turn this lesson into a real-world query artifact by writing one clean business report query and validating output quality.

NULL means unknown or missing — it is not zero, not an empty string, and not false.

Why NULL is special

Comparing anything to NULL with = or != always yields NULL (not TRUE or FALSE):

-- This returns NO rows, even if manager_id is NULL
WHERE manager_id = NULL   -- WRONG

-- This is correct
WHERE manager_id IS NULL

IS NULL and IS NOT NULL

-- Employees with no manager assigned
SELECT first_name, last_name
FROM employees
WHERE manager_id IS NULL;

-- Employees who have a manager
SELECT first_name, last_name
FROM employees
WHERE manager_id IS NOT NULL;

COALESCE — replace NULL with a default

COALESCE(a, b, c, ...) returns the first non-NULL argument:

SELECT
  first_name,
  COALESCE(manager_id::text, 'No manager') AS manager
FROM employees;

NULLs in aggregates

Most aggregate functions (SUM, AVG, COUNT(col)) silently skip NULLs. COUNT(*) counts all rows including those with NULLs.

Tips

  • When you LEFT JOIN and the right side is NULL, use IS NULL to detect unmatched rows (covered in Joins).
  • NULLIF(a, b) returns NULL when a = b — useful to avoid divide-by-zero: salary / NULLIF(hours, 0).

Learning context

This lesson is part of Filtering & Logic. Focus on the core idea in Working with NULL, then validate with deliberate practice.

What to master

  • Understand clause order and intent
  • Write deterministic result queries
  • Use clear aliases and readable structure

Common mistakes

  • Skipping ORDER BY in final outputs
  • Using joins before validating base rows
  • Not checking row counts after changes

High-level strategy

  • Start simple, then layer complexity
  • Run often and compare expected shape
  • Refactor with CTEs when logic grows

Task ladder

  1. Baseline query: get a correct first output.
  2. Add one complication: edge case, join, filter, or ranking rule.
  3. Re-run and refine until output is stable and explainable.

Transparent data checks

  • Check row count before and after each major clause.
  • Validate one manual sample row for correctness.
  • Confirm final ordering and column naming for trust.

Retention loop

  • Run the solution once.
  • Rewrite from memory with one variation.
  • Explain the logic in plain English in one sentence.

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

Quick check: Working with NULL

3 quick questions. One at a time. Instant score at the end.

Exercise 1

Employees without a manager

Enterprise Workforce Analyticseasy

Return first_name and last_name of HR employees who have NO manager (manager_id is NULL).

Run a query to see results here.
Exercise 2

Patients with recorded gender

Clinical Care Performanceeasy

From the hospital sandbox, return first_name and last_name of patients whose gender is recorded (not NULL).

Run a query to see results here.
Exercise 3

Employees with both a manager and a department

Enterprise Workforce Analyticseasy

Return first_name and last_name of employees who have both a manager_id and a department_id (neither is NULL). Order by last_name.

Run a query to see results here.

Lesson 3 of 4

0/3 solved (0%)

← Previous

Finish this lesson to unlock next.