Your First Query: Asking a Database a Question

Time to write your first real query. No setup, no installation, no scary terminal — just two words that unlock every database you'll ever meet.

Remember the restaurant analogy from the last post? You're sitting at the table, and you're about to place your first order. In SQL, that order is a query, and it's built from two essential ingredients: SELECT and FROM.

Queries are questions

The single most important mental shift is this: a SQL query is just a question, written precisely.

When you ask a colleague "what are our best-selling products?", you're doing the same mental work as a query — you've decided what you want to know (the products) and where to find it (the sales records). SQL just makes both halves explicit.

• SELECT = what you want back. Which columns? Which pieces of information?
• FROM = where it lives. Which table holds that information?

That's the entire skeleton. Almost every query you'll write for a long time starts with these two words.

Meet the employees table

Let's imagine a growing Nairobi business — a shop we'll call Soko Fresh, which sells groceries and household goods online and delivers across the city. (If you run a small business, it's basically you.)

Soko Fresh keeps its staff in a table called employees. A table is just data arranged in rows and columns, like a spreadsheet. Here's a slice of it:

Each row is one employee. Each column is one attribute — their name, department, monthly salary in Kenyan shillings, and the city where they're based.

Now let's ask the database questions about this table.

Question one: show me everything

The simplest possible question is "give me all of it." In SQL, the * symbol (pronounced "star") means "all columns." So:

SELECT * FROM employees;

Plain English: "Select all columns, from the employees table."

That's it. That's a complete, valid SQL query. The semicolon at the end is just a full stop — it tells the database the sentence is finished. If you ran this, you'd get the entire table back, exactly as above.

The * is handy for a quick peek, but here's a habit worth building early: in real work, you rarely want everything. Pulling every column is like asking a waiter to bring you the entire menu when you only wanted the ugali and fish. It's wasteful, and it clutters your answer with data you don't need.

Question two: show me just the names

Let's be more specific. Suppose you want a list of every employee's name, and nothing else:

SELECT name FROM employees;

Plain English: "Select the name column, from the employees table."

The result would be a single, tidy column:

Notice what changed: we swapped the * for a specific column name. That's the whole pattern — you list exactly the columns you want, separated by commas.

Question three: two columns at once

What if you need names and departments — say, to print a staff directory? You list both columns after SELECT, separated by a comma:

SELECT name, department FROM employees;

Plain English: "Select the name and department columns, from the employees table."

The result:

There's no limit to how many columns you can list — SELECT name, department, city, salary FROM employees is perfectly fine. The point is that you decide exactly what comes back.

Question four: rename things with AS

One more trick, then we'll tie it together. Sometimes a column name is ugly or unclear, and you want to give it a cleaner label in your result. You do that with AS, which means "show this as that":

SELECT name AS employee_name, salary AS monthly_pay FROM employees;

Plain English: "Select the name column but call it employee_name, and the salary column but call it monthly_pay, from the employees table."

The data is identical — you're just relabelling the output so it's clearer to whoever reads it. This is called aliasing, and you'll use it constantly, especially once you start summarizing data.

The pattern to remember

Before we go further, step back and look at what you now know. Every query so far has followed one exact shape:

SELECT <what you want>
FROM <where it lives>;

That's it. SELECT the columns, FROM the table. You now understand the foundation that every other SQL concept is built on. Filtering, sorting, counting, joining — they're all just additions to this same two-word skeleton.

Formatting is for humans, not the database

One thing that surprises every beginner: SQL does not care about your line breaks, spacing, or capitalisation. These two queries are completely identical to the database:

SELECT name, department FROM employees;

select name, department
from employees

The first squashes everything onto one line; the second spreads it out with lowercase keywords. Both return exactly the same rows. So why do we write SQL the tidy way, with SELECT on its own line and keywords in uppercase? For other people — and future you — to read. Conventions like capitalising the keywords and putting each clause on its own line exist purely to make a query scannable, the same reason we use paragraphs and punctuation in English. When your queries grow past a few lines, good formatting stops being a nicety and becomes a survival skill. The habit is worth forming from day one.

Try it yourself

You don't need to install anything to practise. Head to sqlbolt.com, which runs SQL right in your browser with tiny example tables. Click through the first two lessons ("SELECT queries 1" and "2") and type each query yourself. Pay attention to how the questions are phrased in plain English, and how each maps to SELECT ... FROM ....

Here's your homework for this post:

Write the queries that would answer each of these questions about the employees table:

1. Show me every column for every employee.
2. Show me just the cities where employees are based.
3. Show me the name and salary of every employee.
4. Show me the department of every employee, but relabel the column as team.

When those feel easy, you're ready for the next post — where we stop pulling everything and start pulling exactly the right thing. That's where SQL goes from "neat trick" to genuinely useful.