Filtering the Noise — Finding What Matters

Last post, we learned to pull data with SELECT ... FROM .... But here's the problem: pulling everything is rarely useful. Real databases hold thousands or millions of rows, and the skill that separates useful answers from overwhelming dumps is one small word: WHERE.

WHERE is how you filter. It's how you say "not all of it — just the part I care about." And once you get it, most of what a business actually asks of its data becomes straightforward.

The inbox analogy

Think about your email inbox. You don't scroll through all 8,000 messages every time you need something — you search. You type "invoice from KPLC", or filter to unread messages from a specific person, or find everything from last month.

WHERE is exactly that search box, applied to a database. You tell SQL the conditions a row must meet to make it into your result, and everything else gets left out.

The shape looks like this:

SELECT <columns>
FROM <table>
WHERE <condition>;

The WHERE clause always comes after FROM, and it's followed by a condition that is either true or false for each row. Rows where it's true stay; rows where it's false are dropped.

Meet the comparison operators

To write conditions, you need to compare things. SQL gives you the same comparison operators you'd use in plain English:

We'll keep working with our employees table from Soko Fresh:

Filter by department

Your first real business question: who's in Sales?

SELECT name FROM employees
WHERE department = 'Sales';

Plain English: "Show me the names, from the employees table, where the department equals Sales."

Two things to notice. First, 'Sales' is wrapped in single quotes — in SQL, text values always go in single quotes. Second, the result:

Three rows. Everyone else — Engineering, Finance, Customer Success — was filtered out. That's WHERE doing its job.

Add a numeric condition

Now let's get specific. Who earns more than 150,000 shillings a month?

SELECT name, salary FROM employees
WHERE salary > 150000;

Plain English: "Show me name and salary, from employees, where salary is greater than 150,000."

Notice numbers don't take quotes — only text does. salary > 150000 is a number comparison; department = 'Sales' is a text comparison.

Combine conditions with AND

Real questions usually have more than one condition. Who's in Engineering AND earns more than 180,000?

SELECT name, salary FROM employees
WHERE department = 'Engineering' AND salary > 180000;

Plain English: "Show me name and salary, from employees, where the department is Engineering and the salary is greater than 180,000."

AND means both conditions must be true. The result:

Mercy Chebet is in Engineering but earns 160,000, so she's excluded — AND demanded both.

One condition OR the other

Sometimes you want either condition to qualify. Who works in Finance OR Customer Success?

SELECT name, department FROM employees
WHERE department = 'Finance' OR department = 'Customer Success';

Plain English: "Show me name and department, from employees, where the department is Finance or Customer Success."

OR means at least one condition must be true. The key difference from AND: with OR, a row qualifies if either side is true; with AND, it qualifies only if both sides are true.

Pattern matching with LIKE

Here's a powerful one. What if you only remember part of a value? Maybe you want everyone whose name starts with "A", or every email ending in @gmail.com. That's what LIKE is for.

LIKE matches text patterns using two wildcards:

• % means "any number of characters" (including zero).
• _ means "exactly one character."

So 'A%' means "starts with A, then anything." Let's find every employee whose name starts with "A":

SELECT name FROM employees
WHERE name LIKE 'A%';

Plain English: "Show me names, from employees, where the name starts with 'A'."

Only Achieng — the sole name starting with A. What about names containing "a" anywhere? That's '%a%' (anything, then 'a', then anything):

SELECT name FROM employees
WHERE name LIKE '%a%';

This would match Wanjiku Kamau, Achieng Nyambura, Peter Mwangi (the "a" in Mwangi), Njeri Waweru, David Kiprop, and Samuel Omondi. LIKE is case-sensitive in most databases, so capital letters behave differently from lowercase — a common gotcha worth remembering.

A real business scenario, end to end

Let's put it together into something that feels like an actual Monday morning. Soko Fresh's HR lead asks you three questions. Here's how each becomes a query:

1. "Who's on the Sales team based in Nairobi?"

SELECT name FROM employees
WHERE department = 'Sales' AND city = 'Nairobi';

Result: just Wanjiku Kamau.

2. "Who earns less than 100,000, so we can review pay?"

SELECT name, salary FROM employees
WHERE salary < 100000;

Result: Otieno Ochieng (95,000), David Kiprop (90,000), Samuel Omondi (65,000).

3. "Who's in Engineering or Finance?"

SELECT name, department FROM employees
WHERE department = 'Engineering' OR department = 'Finance';

Result: the four Engineering staff plus Njeri from Finance.

Notice how each question maps cleanly onto the SELECT → FROM → WHERE skeleton. Once you can hear a business question and see the query behind it, you're most of the way there.

The order matters

One thing that trips people up: the order of the keywords is fixed. It's always SELECT, then FROM, then WHERE. Write WHERE before FROM and the database will complain.

SELECT name, salary
FROM employees
WHERE salary > 150000;

That's the correct order. Reading it aloud — "select name and salary, from employees, where salary is greater than 150,000" — even sounds like English, which is exactly the point.

Try it yourself

On sqlbolt.com, work through the lessons on filtering (WHERE, and the "filtering and sorting" exercises). Then, for our employees table, write the query for each:

1. Everyone based in Kisumu or Mombasa.
2. Everyone in Engineering earning at least 160,000.
3. Every employee whose name starts with "N".
4. Everyone whose department is not Sales.

Next up, we'll take the rows you've filtered and put them in a sensible order — because knowing which customers are your biggest is far more useful than a jumbled list of all of them.