Your First SELECT Query
A SELECT query turns stored rows into a result shaped for a question. You choose the source table with FROM, choose the output columns with SELECT, and can rename or calculate values without changing the stored data.
A query has a source and an output shape
FROM identifies the table whose rows you want to read.SELECT chooses which values appear in each output row.AS gives the returned columns names useful to readers and callers.course_id · title · category · duration_minutes · price_centsFour course rows are available to read.
FROM courses;The query requests two values from each row.
SQL Foundations · 90The result has two columns and four rows.
Read a table with SELECT and FROM
SELECT title, duration_minutes FROM courses; asks for the title and duration of each course row. The comma separates output expressions; FROM courses names the source table; the semicolon ends the statement. SQL keywords are conventionally written in uppercase to make them easy to scan, but SQLite does not require uppercase keywords.
The result is a new table-shaped answer. It does not remove other columns from courses, edit any row, or save a new table. Run the query, then compare the result headings with the five columns in the table definition.
Run your first SELECT query
Create four course rows and request just title and duration from each one.
Edit the query, predict the rows it will return, then run it.
Projection chooses columns, not rows
Choosing columns is called projection. Every selected source column becomes a column in the result, in the order you list it. At this stage, all four course rows remain because the query has no condition. Filtering rows with WHERE is the next lesson; adding or removing a projected column does not filter a row.
Change the result shape
Return the identity, title, and category for every course, in that order.
Edit the query, predict the rows it will return, then run it.
Use SELECT * to inspect, then name the contract
SELECT * returns every column from the source table. It is useful when you are exploring a small table, but an application usually needs an explicit list. If a new column is added later, * silently changes the output shape. It can also return large or sensitive columns the caller did not need. Explicit columns make the query’s purpose and result contract reviewable.
Compare a wildcard with explicit columns
Run both queries and compare their headings and values in the output panel.
Edit the query, predict the rows it will return, then run it.
Aliases name the output, not the stored column
An alias follows an expression: title AS course_title. The result heading becomes course_title, while the column in the table remains title. Aliases are especially useful when a report needs friendly names or a calculated value needs an understandable heading. Use short, descriptive identifiers; spaces in aliases require dialect-specific quoting and are best avoided in application-facing results.
Give result columns useful names
Rename three output columns without changing the table schema.
Edit the query, predict the rows it will return, then run it.
SELECT can calculate a value for each row
The select list can contain expressions as well as column names. price_cents / 100.0 AS price_dollars converts cents for display. The decimal 100.0 matters in this SQLite example: using an integer divisor can produce integer division and lose the cents. duration_minutes + 15 computes a hypothetical break-adjusted duration. Neither calculation writes back to the table.
Compute named result values
Compare stored cents and minutes with calculated dollars and break-adjusted minutes.
Edit the query, predict the rows it will return, then run it.
Literals and NULL can appear in a result
A select list may include a literal such as 'SovranCode' AS provider. The same label appears in every output row because it comes from the query, not the table. NULL AS reviewed_on represents an unknown or absent value. The expression price_cents = 0 AS is_free evaluates a comparison for each row; SQLite displays the boolean result as 1 or 0. Other database systems may display boolean values differently.
Add labels and a simple comparison
Add output values that are computed from literals or a condition, while leaving stored rows untouched.
Edit the query, predict the rows it will return, then run it.
Result order is not promised without ORDER BY
Small examples often appear in insertion order, which can create a false sense of certainty. A SELECT query without ORDER BY does not promise row order, even when rows appear stable in this runner. Indexes, plans, or data changes can alter it. In this lesson, compare result shapes and values as sets of rows. Sorting and limiting results are taught later in this module.
Common first-query mistakes
Missing FROM
Name the source table with FROM courses before asking SQLite to read its columns.
Missing comma
Separate expressions with commas. Without one, SQL may interpret the second identifier as an alias instead.
Unstable output
Choose only the columns the caller needs so a schema change does not silently expand the response.
Assumed row order
A repeated-looking order is still not a guarantee. Use ORDER BY when order matters.
Independent lab: build a course card feed
Using the four seeded courses, return one result row per course with course_id, a course_name alias, duration in hours, price in dollars, and a constant provider label. The starter query already runs. Rebuild it from a blank SELECT list, then add a price_label or is_free expression of your own. Explain which values are stored and which exist only in the result.
Shape a course card result
Create an application-ready output without altering the source table.
Edit the query, predict the rows it will return, then run it.
Lesson review
FROM names the source table. SELECT shapes the result by choosing columns, literals, or expressions. AS labels output columns without renaming stored fields. A wildcard is useful for exploration, but explicit columns make stable, narrow output. Projection changes columns, not the number of source rows; the next lessons will add filtering, sorting, and limiting.
- I can write a readable SELECT ... FROM ... query.
- I can predict the columns and row count of a projection.
- I can explain why an explicit column list is useful for application output.
- I can use AS to name result columns without changing the table.
- I can calculate a named value and distinguish it from stored data.
- I know that a result has no guaranteed row order without ORDER BY.