SELECT, WHERE, ORDER BY | Relational Databases

In this chapter

We'll ask GreenMart's tables a real question for the first time — meeting SELECT, WHERE, and ORDER BY, the three commands behind almost every question a database ever answers.

12–15 min

The Problem in Real Life

"Just tell me — how much did we actually sell today?" Mike asks. It sounds like the simplest question in the world. Sarah has real data now — two chapters of typing sales, customers, and products into actual tables instead of notebook pages. But typing data in and asking a question back out turn out to be two completely different skills.

Sarah already knows INSERT and UPDATE. Neither one reads anything back. The command that finally lets GreenMart's database answer a question — this row, not that one, in this order — is one she hasn't touched yet.

Give me a second... I'm teaching it to answer that.

Sarah

Reading Every Row vs. Asking One Question

Data that's never been asked anything

Two chapters of INSERT and UPDATE never once read a row back out.

Ten rows or ten thousand

Without WHERE, a query returns every single row in the table, whether Mike wanted one or all of them.

No guaranteed order

A table has no built-in top-to-bottom order — without ORDER BY, rows can come back in any sequence at all.

The real number needs two tables

Sales knows which product sold; Products knows what it costs. Today's total needs both, together.

What Do SELECT, WHERE, and ORDER BY Actually Do?

Chapters 1 and 2 were entirely about writing: CREATE built the tables, INSERT and UPDATE filled them with real data. None of that lets anyone read anything back. The command that actually asks a table a question is called SELECT — and in practice, it almost never works alone.

Three pieces work together nearly every time GreenMart wants an answer: SELECT picks which columns to see, WHERE picks which rows qualify, and ORDER BY decides what order they come back in. Leave any one of them out, and the query still runs — it just answers a slightly different question than the one Mike actually asked.

Table — Every Row in Customers, Unfiltered

CustomerID	Name	Phone	BalanceDue
101	Priya	555-0142	140
102	Alex	555-0198	0
103	Maria	555-0173	75
104	Devon	555-0233	0
105	Raj	555-0281	20
106	Neha	555-0309	0
107	Farah	555-0357	50
108	Tom	555-0392	0
109	Leah	555-0416	15
110	Omar	555-0468	0

"BalanceDue" is a column — every row has this fact

Table — After WHERE BalanceDue > 0, Ordered by BalanceDue DESC

Name	BalanceDue
Priya	140
Maria	75
Farah	50
Raj	20
Leah	15

"BalanceDue" is a column — every row has this fact

Five rows out of ten survived WHERE. ORDER BY put the largest balance first — the exact same table, answering a completely different-looking question.

SELECT chooses which columns to return. SELECT * returns every column; naming columns returns only those.

Asking for Specific Columns

SELECT Name, Phone
FROM Customers;

Only two columns come back, not every column in the table. SELECT * would work too, but naming exactly what's needed is almost always the better habit.

WHERE filters which rows qualify, using conditions like =, >, and <.

Filtering With WHERE

SELECT Name, BalanceDue
FROM Customers
WHERE BalanceDue > 0;

Ten customers exist in the table. Only the ones with an actual balance due come back — WHERE decides that before anything else happens.

AND combines two or more conditions inside a WHERE clause — every condition has to be true for a row to qualify.

Combining Conditions With AND

SELECT *
FROM Sales
WHERE SaleDate = '2026-08-29'
  AND CustomerID = 101;

Both conditions have to be true for a row to qualify — today's date, and this specific customer. Change AND to OR, and the meaning changes completely: either condition alone would be enough.

ORDER BY sorts the rows that come back, ascending by default or with DESC for descending.

Sorting Results With ORDER BY

SELECT Name, BalanceDue
FROM Customers
WHERE BalanceDue > 0
ORDER BY BalanceDue DESC;

The same WHERE as before, but now the results come back largest balance first. Without ORDER BY, there's no guarantee what order they'd show up in at all.

Notice the order these three ideas actually answer, even though it's not the order they're written in: WHERE decides which rows survive, SELECT decides what those rows look like, and ORDER BY decides what sequence they show up in. All three can point at the exact same table and return three completely different-looking results.

Sarah can now tell Mike exactly who owes GreenMart money, and in what order. The one question Mike actually asked — how much did we sell today — still needs one more piece: Sales only records which product sold, and Products only records what it costs. Putting a real dollar total on today's sales means connecting those two tables together, which is exactly what a JOIN does — the very next skill, waiting in Act 3.

Key Takeaway

SELECT chooses the columns, WHERE chooses the rows, and ORDER BY chooses the sequence — the same table can answer completely different questions depending on how these three are combined.

Why This Matters

Nearly everything left in this course is really about getting better at asking questions — aggregate functions, joins, subqueries, even indexes years from now are all in service of a SELECT statement returning the right rows, in the right order, fast enough. This chapter is the first time GreenMart's database gets to answer anything at all.

GreenMart's tables can finally answer real questions — just not Mike's exact one yet. The next chapter deals with a specific kind of missing answer: what happens when a value simply isn't there at all.