Your First SELECT

Everything Lora wants to know about her cinema — as opposed to everything she wants to store — starts with one word. SELECT is the SQL verb for reading data, and you will use it more than all the other verbs combined. Ask which films are playing, which seats are booked, which customers joined last month: every one of those questions begins with SELECT, and every one comes back answered.

So let's ask the very first question: show me the whole poster wall. In SQL that is select everything from the films table, and the plan for this page is simple — read that sentence until its shape feels like grammar rather than code. Once the shape is yours, the rest of the chapter is just adding rooms to a house whose frame you already know.

The Shape of the Sentence

Here is the query. Read it out loud in English first: select everything, from the films table. Then look at the SQL, which says exactly that, in the same order:

SELECT * FROM films;

Two words carry the structure. SELECT names which columns you want to see, and FROM names which table to read them from. That's the entire sentence shape: SELECT what, FROM where. Every query in this book — including the intimidating-looking ones near the end — survives being read aloud that way, and reading aloud is genuinely how you should check any query you don't understand yet.

The database answers with a table. For the Marquee's three films, the answer looks like this:

Notice what did not happen: the films table was not opened, edited, locked, or changed in any way. SELECT only reads. You could run this query a thousand times, mistype it, ask for nonsense — the stored data stays exactly as it was. Ordering at a counter is the right picture: you name what you want from the menu, the kitchen decides how to fetch it and hands over a copy of the dish. You never walk into the kitchen, and asking twice just gets the same dish twice. That's the whole analogy — from here on, we say query and result.

What Does the Star Mean?

The * in that first query is a wildcard meaning "all columns" — give me every column the table has, in the order the table declares them. It saves typing, and when you're exploring a table you've never met, it is exactly the right tool: one star and you see everything the table knows.

Both truths in one honest sentence, though: * is convenient at the keyboard and sloppy in real code, because a query that says "everything" silently changes its answer the day someone adds a column to the table. Professionals type the star while exploring and name their columns in anything that has to keep working. You now know both habits and when each applies.

Choosing Columns

Naming columns is the same sentence with the star replaced by a list. Suppose Lora is printing a schedule and only needs each film's title and length — select the title and the runtime, from the films table:

SELECT title, runtime_min FROM films;

The answer is still a table — just a narrower one. And the columns came back in the order you listed them, which didn't have to match the table's own order at all. Ask for runtime_min, title and you'd get the same facts with the columns swapped. The result is your table, shaped your way; the stored table doesn't move.

Pause on that phrase, because it is the quiet engine of the whole book: every query returns a table. Not a report, not a printout — a table, with rows and columns, exactly the kind of thing you spent Chapter 2 learning to read. When JOINs and subqueries arrive later, they will feel inevitable instead of magical for precisely this reason: anything that produces a table can feed anything that reads one.

Conventions That Aren't Rules

One last thing before you write queries of your own: some of what you've seen is law, and some is just good manners. The UPPERCASE keywords are manners. SQL doesn't care — select * from films; runs identically — but people everywhere write keywords in caps and table and column names in lowercase, so a reader's eye can separate the fixed grammar from the parts that name your data. This book follows the convention, and so should you.

The semicolon at the end marks where a statement stops. Some tools forgive a missing one when you run a single query; get in the habit anyway, because every tool accepts it and some require it. The engine doesn't care about your capitalization and barely cares about your semicolon — colleagues care about both, and you'll be writing for colleagues soon enough.