Julia Fischer, who leads customer support, sends two questions: “How many tickets are still open? And what’s our average satisfaction score?” Both answers depend on the same value, and it’s the one that causes more wrong numbers in analytics than any other: NULL.
In support_tickets, closed_at is NULL while a ticket is open, and satisfaction is NULL when the customer never rated it. NULL doesn’t mean zero or empty text. It means unknown.
Try finding open tickets the way you’d find anything else:
\nSELECT COUNT(*) AS open_tickets\nFROM support_tickets\nWHERE closed_at = NULL;Zero. Is closed_at equal to NULL? SQL’s answer is “unknown”, because comparing anything with an unknown value gives an unknown result, even NULL = NULL. And WHERE keeps a row only when its condition is TRUE, never when it’s unknown. The test for missing values has its own syntax:
SELECT COUNT(*) AS open_tickets\nFROM support_tickets\nWHERE closed_at IS NULL;56 open tickets. This is three-valued logic: every condition is TRUE, FALSE or NULL. AND and OR follow the tables below. The rule of thumb: NULL wins unless the other side settles the answer on its own (FALSE for AND, TRUE for OR).
\nThe dangerous case isn’t = NULL, which returns nothing and gets noticed. It’s a “not equal” filter on a column that has NULLs:
SELECT\n (SELECT COUNT(*) FROM orders WHERE coupon_code <> 'BLACKFRIDAY25') AS with_not_equal,\n (SELECT COUNT(*) FROM orders WHERE coupon_code IS DISTINCT FROM 'BLACKFRIDAY25') AS null_safe;264 versus 1,942. “Orders that didn’t use BLACKFRIDAY25” obviously includes the 1,678 orders with no coupon at all, but <> dropped every one of them. IS DISTINCT FROM treats NULL as a comparable value, so it’s the NULL-safe version of <>. SQLite also accepts the shorter IS NOT 'BLACKFRIDAY25'; PostgreSQL only accepts IS DISTINCT FROM.
Aggregates skip NULLs, which is usually what you want but always worth stating:
\nSELECT\n COUNT(*) AS tickets,\n COUNT(satisfaction) AS rated,\n ROUND(AVG(satisfaction), 2) AS avg_score,\n ROUND(AVG(COALESCE(satisfaction, 0)), 2) AS wrong_avg\nFROM support_tickets;COUNT(*) counts rows (873); COUNT(satisfaction) counts known values (588). AVG divides by the known count, giving 3.74. Replacing NULL with 0 using COALESCE drags the average to 2.52, inventing 285 furious customers who never said anything. Report Julia the 3.74 and the response rate, 588 of 873: an average over two-thirds of tickets should say so.
COALESCE(a, b, ...) returns its first non-NULL argument and is right for display defaults, like COALESCE(coupon_code, 'none'). Its mirror image is NULLIF(a, b), which returns NULL when a = b. Dividing by NULLIF(denominator, 0) gives NULL instead of a divide-by-zero error in engines that raise one.
NULL is one marker for several different situations, and the right treatment depends on which one you’re looking at. In Cartwheel alone:
\nclosed_at is NULL because the event hasn’t happened yet. Count these as open, and exclude them from resolution times.satisfaction is NULL because the customer didn’t answer. Report the response rate next to the average.coupon_code is NULL because the order had no coupon. Here NULL really means “none”, so COALESCE(coupon_code, 'none') is a fair label.referred_by is NULL because the customer wasn’t referred, or because nobody recorded it. You can’t tell which, and you should say so.NULLs also affect sorting. SQLite puts NULLs first in ascending order and last in descending order; PostgreSQL does the opposite. If the position matters, say it explicitly with ORDER BY satisfaction NULLS LAST, which both engines accept.
Julia also wants a readable status for each ticket; that one is your exercise. Here is the same tool on orders, labelling how each one was priced. CASE evaluates its WHEN conditions top to bottom and returns the first match:
SELECT\n order_id,\n coupon_code,\n shipping_fee,\n CASE\n WHEN coupon_code IS NULL AND shipping_fee = 0 THEN 'free shipping only'\n WHEN coupon_code IS NULL THEN 'full price'\n WHEN coupon_code = 'FREESHIP' THEN 'coupon: shipping'\n ELSE 'coupon: discount'\n END AS price_type\nFROM orders\nORDER BY order_id\nLIMIT 6;Two rules make CASE reliable. Order the WHENs from most specific to most general, because the first TRUE branch wins and the rest are never checked. And write an ELSE on purpose: without one, unmatched rows get NULL, which then flows into everything downstream. SQLite also has IIF(condition, a, b) for two-way choices, but CASE is standard SQL and works in every engine.
Missing values are one source of surprise; dates are the other, and they’re next.
\n","toc":[{"id":"sec-1","text":"Unknown is contagious","level":2},{"id":"sec-2","text":"Where NULL quietly drops rows","level":2},{"id":"sec-3","text":"NULL in aggregates","level":2},{"id":"sec-4","text":"Decide what each NULL means","level":2},{"id":"sec-5","text":"CASE: labels from logic","level":2}],"takeaways":["Any comparison with NULL, including NULL = NULL, returns NULL (unknown), and WHERE keeps only rows where the condition is TRUE.","Test for missing values with IS NULL or IS NOT NULL; use IS DISTINCT FROM (or IS NOT in SQLite) for a NULL-safe “not equal”.","COUNT(*) counts rows, COUNT(column) counts non-NULL values, and AVG ignores NULLs instead of treating them as zero.","A CASE expression returns the result of the first WHEN that is TRUE, so put the most specific conditions first and always decide what ELSE should be."],"further":[{"title":"NULL handling in SQLite versus other engines","url":"https://www.sqlite.org/nulls.html"},{"title":"SQLite CASE expression and IS DISTINCT FROM","url":"https://www.sqlite.org/lang_expr.html#the_case_expression"},{"title":"PostgreSQL comparison functions and operators","url":"https://www.postgresql.org/docs/current/functions-comparison.html"}],"quiz":[{"q":"orders.coupon_code is NULL for most orders. How many rows does WHERE coupon_code <> 'FREESHIP' keep?
NULL <> 'FREESHIP' is NULL, not TRUE, so those rows are dropped."},{"text":"Only orders that used some other coupon; orders without a coupon are dropped.","why":"Correct. The comparison is unknown for NULL coupons, and WHERE keeps only TRUE rows. Use coupon_code IS DISTINCT FROM 'FREESHIP' to keep them."},{"text":"No rows, because the column contains NULLs.","why":"NULLs only affect their own rows. Orders with a non-NULL coupon still compare normally."}],"answer":1},{"q":"A ticket table has 10 rows; 4 have satisfaction NULL and the other 6 average 4.0. What does AVG(satisfaction) return?
What label does a ticket with satisfaction = 1 get?
CASE\n WHEN satisfaction <= 3 THEN 'neutral'\n WHEN satisfaction <= 2 THEN 'unhappy'\n ELSE 'happy'\nEND1 <= 3 is TRUE, so the ‘unhappy’ branch is never reached. Order WHENs from most to least specific."},{"text":"‘unhappy’","why":"It would be if the WHENs were in the other order. CASE doesn’t look for the best match, only the first."},{"text":"‘happy’","why":"ELSE only applies when no WHEN is TRUE, and the first one is."}],"answer":0},{"q":"Which expression safely computes refunds / orders when orders can be 0?
refunds / orders","why":"In SQLite, dividing by zero returns NULL rather than an error, but other engines like PostgreSQL throw, and the intent isn’t visible to a reader."},{"text":"COALESCE(refunds / orders, 0)","why":"This turns “can’t compute” into 0, which misreports a ratio that has no denominator as a real zero."},{"text":"refunds / NULLIF(orders, 0)","why":"Correct. NULLIF turns a zero denominator into NULL, so the result is NULL (“no data”) in every engine, which is honest and portable."}],"answer":2}],"exercise":{"kind":"sql","starter":"-- Urgent tickets with a readable state\nSELECT\n ticket_id,\n CASE\n WHEN closed_at = NULL THEN 'open'\n WHEN satisfaction = NULL THEN 'unrated'\n WHEN satisfaction <= 2 THEN 'unhappy'\n ELSE 'happy'\n END AS state\nFROM support_tickets\nWHERE priority = 'urgent'\nORDER BY ticket_id;","solution":"SELECT\n ticket_id,\n CASE\n WHEN closed_at IS NULL THEN 'open'\n WHEN satisfaction IS NULL THEN 'unrated'\n WHEN satisfaction <= 2 THEN 'unhappy'\n ELSE 'happy'\n END AS state\nFROM support_tickets\nWHERE priority = 'urgent'\nORDER BY ticket_id;","orderMatters":true,"title":"Label Julia's urgent tickets","prompt":"Julia wants every urgent ticket with a state label, checked in this order:
'open' when the ticket has no closed_at'unrated' when it’s closed but has no satisfaction score'unhappy' when the score is 1 or 2'happy' otherwiseReturn ticket_id and state, sorted by ticket_id. Order matters. The starter labels almost everything ‘happy’. Find out why and fix it.
closed_at = NULL evaluate to, for any row?","A CASE branch is taken only when its condition is TRUE. NULL (unknown) isn’t TRUE, so the row falls through to ELSE.","Use IS NULL in the first two WHEN branches."],"explanation":"closed_at = NULL is NULL for every row, so the first two branches never fire, and an open, unrated ticket falls past satisfaction <= 2 (also NULL) into ELSE: ‘happy’. With IS NULL, open tickets are caught first. The branch order also matters: elsewhere in the table a few open tickets already carry a score, and because ‘open’ is checked first they’re labelled open, which is what Julia’s rules say.