FROM and Table References in SQL

FROM is how you tell SQL which table to read from.

Without it, SELECT has nothing to work with. You can write arithmetic with just SELECT — quick calculations, labeled values — but the moment you need real data from the database, you need FROM to point SQL at the right place.

Think of a database like a filing cabinet where each drawer is a table. customers, products, orders — each one holds a different set of rows. FROM is you opening a specific drawer and telling SQL: start here. Every row in that drawer becomes available. SELECT then picks which columns to return.

You'll use this pattern constantly as an analyst. A manager asks for a customer list. A stakeholder wants the product catalog. An ops person needs to see all recent orders. Every one of those starts the same way:

SQL reads the customers table and returns every row with two columns: name and email. Nothing else, regardless of how many other columns exist in the table.

Different table, completely different data:

Change customers to products and you're in a different drawer entirely. The query structure is identical; the data is completely different.

When you're exploring a table for the first time, SELECT * returns every column at once. It's the fastest way to see what a table actually contains before you decide what you need.

One rule matters here: every column you name in SELECT has to exist in the table FROM points to. SQL checks this before running the query. Ask for a column that isn't there and you get an error immediately — not a blank result, not a null, an error.