SQL Basics: Asking a Database for What You Want

A database is essentially a giant filing cabinet full of spreadsheet-like tables, and SQL, which stands for Structured Query Language, is how you politely ask that cabinet for exactly what you need. The encouraging thing about SQL is that almost every question you ask follows the same basic shape: give me these columns, from this table, trimmed down in these ways. Once that shape clicks, the rest of SQL is just learning new ways to slice and filter. This guide covers the core vocabulary, enough to start exploring any database with confidence.

SELECT and FROM: The Two Keywords Every Query Needs

The foundation of every query is a pair of keywords that always appear together. SELECT chooses which columns you want, and FROM says which table to take them from.

SELECT *
FROM books;

Read this the way SQL means it: select all columns, where the asterisk is a wildcard meaning “everything,” from the table called books. The semicolon at the end is the full stop of the sentence; it tells the database you are done and it can run the query. Two clauses, two keywords, and the result is a copy of the entire books table.

In practice, though, you usually want to name the specific columns you care about rather than grabbing everything:

SELECT title, author
FROM books;

This is the same shape, but instead of the wildcard you list the columns you actually want, separated by commas. There are two good reasons to prefer this. The first is speed: pulling two columns is faster than pulling fifty, especially across a network. The second is clarity: the query explicitly states that you care about title and author, which makes your intent obvious to anyone reading the code later. Treat SELECT * as a tool for quick exploration, and name your columns in real work.

One rule never changes: SELECT always comes first, then FROM. That order is fixed.

DISTINCT: Removing Duplicate Values

Often a column contains the same value many times over. If your books table has 500 rows and one author wrote 60 of them, a plain SELECT author returns that author’s name 60 times, once per book. The database has no way of knowing you only care about the unique names; it just hands back whatever sits in those rows.

SELECT author
FROM books;

DISTINCT solves this. It is a one-word filter you place right after SELECT, telling the database to return each unique value only once:

SELECT DISTINCT author
FROM books;

Now each author appears a single time, no matter how many books they wrote. The mental model is a sieve that removes exact copies from your results. It is exactly what you want when you need a list of who or what is in a table, rather than how many of each there are.

There is one subtlety that catches people out. When you select more than one column, DISTINCT deduplicates the whole row, the combination of values, not each column on its own:

SELECT DISTINCT author, genre
FROM books;

If one author wrote both Horror and Fantasy books, this returns two rows for them, (King, Horror) and (King, Fantasy), because those are distinct pairs even though the author’s name repeats. If you wanted unique authors regardless of genre, you would select DISTINCT author alone. The key point is that with multiple columns, it is the combination that must be unique.

AS: Renaming Columns in Your Output

The AS keyword acts as a label-maker for your results. It renames a column in the output without changing anything in the actual table.

SELECT DISTINCT author AS unique_author
FROM books;

Here the column is still called author in the database, but the result set, the table SQL hands back to you, shows it as the friendlier unique_author. This matters more than it first appears. Real-world column names are often cryptic, like usr_acct_id_v2, and renaming them in your output makes reports readable. Aliases also become essential when you join multiple tables that each have a column called id, since they let you tell the two apart.

The pattern is always original AS new_name:

SELECT column_name AS better_name
FROM table_name;

If your alias contains a space or unusual characters, wrap it in double quotes, like AS "Total Sales". Some SQL dialects let you drop the AS word entirely and just write author unique_author, which works, but including AS is far clearer to anyone reading the code, so it is worth always writing it out.

CREATE VIEW: Saving a Query for Reuse

A view is a saved query with a name. Suppose you have written a useful query and find yourself typing it ten times a day. Instead of repeating it, you wrap it once in CREATE VIEW, and from then on you can refer to it by name as though it were a table.

CREATE VIEW library_authors AS
SELECT DISTINCT author AS unique_author
FROM books;

The crucial thing to understand is that a view does not store the results; it stores the recipe. Every time you query the view, the database re-runs the underlying SELECT against the current data. So if someone adds a new author to bookstomorrow, the view reflects that automatically, with no refresh needed. A good analogy is a saved search on a website: the search is not a stored copy of results, it is a query that pulls fresh results every time you run it.

Once the view exists, you query it exactly like a table:

SELECT *
FROM library_authors;

You can select from it, filter it, and join it, and whoever uses the view need not know or care that underneath it is a saved query. This makes views excellent for sharing complex logic with teammates. Rather than explaining a fifty-line query, you create a view and simply tell them to select from monthly_revenue.

The distinction between a table and a view is worth holding onto. A table stores data. A view stores a query. Both can be queried with SELECT, but a view updates automatically because it reruns its query each time, whereas a table simply holds whatever has been written to it.

LIMIT: Controlling How Many Rows Come Back

LIMIT caps the number of rows your query returns, stopping after a set number even if more exist.

SELECT genre
FROM books
LIMIT 10;

This is the difference between asking for a taste and asking for the whole pot of soup, and it matters for two reasons. The first is exploration: when meeting a new table for the first time, you do not want to download all fifty million rows just to see what columns exist, and LIMIT 10 gives you a quick peek. The second is performance: on large tables, returning fewer rows is faster and cheaper.

There is an important caveat. Without an ORDER BY clause, “the first 10 rows” simply means whatever ten rows the database happens to return, in no guaranteed order. So LIMIT 10 is perfect for sampling, but not for finding “the top 10 best-selling books.” For a meaningful top N, you would combine it with ordering, as in ORDER BY sales DESC LIMIT 10, which is a topic for a later lesson. Use LIMIT when exploring a table, when you want a sample from something very large, or, paired with ORDER BY, when you genuinely need the top results.

Putting It All Together

Here is the most feature-complete single query you can write with what we have covered:

SELECT DISTINCT column1, column2 AS alias_name
FROM table_name
LIMIT 10;

Read as a sentence, this says: give me distinct pairs of column1 and column2, calling the second one alias_name, from table_name, and stop after ten rows. Notice the fixed order of the keywords: SELECT, then DISTINCT, then the columns with their optional aliases, then FROM and the table, and finally LIMIT. Almost every SQL query starts from this skeleton and grows out from it, so it is worth committing to memory.

Quick Reference

-- All columns
SELECT * FROM books;
-- Specific columns
SELECT title, author FROM books;
-- No duplicates
SELECT DISTINCT author FROM books;
-- Rename a column in the output
SELECT author AS unique_author FROM books;
-- Save a query as a view
CREATE VIEW view_name AS
SELECT DISTINCT author AS unique_author
FROM books;
-- Query the view
SELECT * FROM view_name;
-- Limit rows returned
SELECT genre FROM books LIMIT 10;

Conclusion

SQL begins with a simple, repeatable shape. SELECT chooses your columns and FROM names your table, and from there each keyword adds one capability: DISTINCT removes duplicate rows, remembering that it works on the whole combination of columns; AS renames columns in your output for readability; CREATE VIEW saves a query so you can reuse it like a table, always running fresh against the current data; and LIMIT caps the rows returned, ideal for sampling but order-blind without ORDER BY. Master this handful of keywords and the fixed order they appear in, and you have everything you need to start exploring any database.

See you soon.