The WHERE clause decides which rows survive. Write a real predicate — comparisons, AND/OR, IN, BETWEEN, LIKE, IS NULL — and this lab parses and evaluates it against every row, showing you exactly which ones matched and why.
The predicate column shows what your condition evaluated to for that row. Only TRUE rows are returned — UNKNOWN is not the same as FALSE, but it is discarded just the same.
The WHERE Clause: Keeping Only What You Asked For
A filter applied to every row, one at a time. Simple — until NULL gets involved.
Quick Context
The WHERE clause is a condition tested against each row independently. If it evaluates to TRUE, the row is kept; anything else and it is dropped. That row-at-a-time model is the key mental picture — the database is not filtering "the table", it is asking one question of every row.
The Operators You Actually Need
Comparison — = <> < > <= >=. Note SQL uses = for equality, not ==.
Logical — AND, OR, NOT. AND binds tighter than OR, so use parentheses when mixing them.
IN (a, b, c) — shorthand for a chain of ORs.
BETWEEN x AND y — inclusive of both endpoints, which surprises people regularly.
LIKE — pattern matching where % is any run of characters and _ is exactly one.
IS NULL / IS NOT NULL — the only correct way to test for missing values.
The NULL Trap: SQL Has Three Truth Values
NULL does not mean zero or empty string — it means unknown. Comparing anything to an unknown gives an unknown result, so manager = 'Ada Lovelace' is neither TRUE nor FALSE for a row where manager is NULL. It is UNKNOWN, and WHERE only keeps TRUE.
Run the two manager examples in this lab and watch the UNKNOWN counter. The consequence catches everyone eventually: WHERE manager = 'X' and WHERE manager <> 'X' together do not return every row. The NULL rows fall through both. To include them you must say OR manager IS NULL explicitly.
WHERE and Performance
WHERE is also where indexes earn their keep. A condition like salary > 65000 can use an index on salary to skip most of the table. But wrapping the column in a function — WHERE UPPER(name) = 'ADA' — usually defeats the index, because the stored values are no longer what is being compared. Similarly, LIKE 'A%' can use an index while LIKE '%a' cannot, since the leading wildcard gives the engine no prefix to seek on.
Interactive Exploration Guide
Run the default predicate. The evaluation column shows TRUE or FALSE for every row — the filter is genuinely parsed and applied, so you can type your own.
Try manager IS NULL, then manager = 'Ada Lovelace'. Watch the UNKNOWN counter appear in the second case.
Test salary BETWEEN 60000 AND 75000 and confirm that a row sitting exactly on an endpoint is included.
Break the syntax on purpose — delete a closing quote. The parser reports the error rather than silently returning nothing, exactly as a database would.
Compare NOT (dept = 'Engineering') OR salary < 65000 with the parentheses removed. Operator precedence changes the answer.
Key Takeaway
WHERE asks one yes/no question of every row — except the answer can also be "unknown", and unknown rows are silently dropped. Most WHERE-clause bugs in production are really NULL bugs.
Cheat sheet
Where Clause in SQL
The WHERE clause decides which rows survive. Write a real predicate — comparisons, AND/OR, IN, BETWEEN, LIKE, IS NULL — and this lab parses and evaluates it against every row, showing you exactly which ones matched and why.