SQL Select Statement Example

In this lesson you’ll examine a simple SQL statement and learn how to read it the way a database engine reads it. Even small queries illustrate the most important idea behind SQL: SQL describes the result set you want, and the database decides how to produce it efficiently.

An example of a very simple statement is:

SELECT * FROM authors;

Read it as: “Return all columns (*) from every row in the authors table.” In relational theory terms, authors represents a relation, and a query returns another relation (a table-shaped result set).

This is valid SQL on most platforms, but it is rarely ideal in production code. The more professional pattern is to list the columns you actually need, because it:

• reduces unnecessary I/O and network transfer,
• keeps application code stable if the table schema changes, and
• improves readability for humans.

SELECT au_id, au_lname, au_fname
FROM authors;

SQL works extremely well in client/server and service-based architectures because it separates: (1) the request (your query) from (2) the execution strategy (how the server finds and returns the rows).

Instead of moving entire tables to an application and filtering them manually, you send a query to the database server. The server uses its optimizer, indexes, and statistics to compute the result set, then returns only the rows and columns you asked for.

In a database context, client/server describes how work is divided:

1. Client: constructs a request (SQL text plus parameters).
2. Server: parses the SQL, validates it, optimizes it, executes it, and builds a result set.
3. Client: receives a result set that is already filtered and shaped for use.

A useful analogy is requesting one file from a filing cabinet: you can either wheel the entire cabinet into your office and sort it yourself (inefficient), or request the exact folder you need and receive only that folder (the SQL approach).

Historically, client/server evolved from: two-tier systems (client + database) into three-tier and N-tier systems (client + application/service tier + database). In modern systems, the application tier is often implemented as web services, APIs, or microservices.

The key architectural idea is still the same: keep data management close to the database, and keep business logic and presentation concerns in the application tier where they can scale, evolve, and be tested independently.

SQL statements are composed of language elements that you will see repeatedly:

1. Clauses: building blocks of statements (for example SELECT, FROM, WHERE).
2. Expressions: produce values (scalars) or derived tables.
3. Predicates: conditions that evaluate to TRUE/FALSE/UNKNOWN (SQL’s three-valued logic).
4. Queries: statements that return result sets.
5. Statements: commands that affect schema, data, transactions, sessions, or diagnostics.
6. Statement terminator: many tools accept ; as a terminator; some require it, others treat it as optional.
7. Whitespace: insignificant whitespace is ignored, which lets you format SQL for readability.

When constructing a query, a practical workflow is: identify the table(s) you need, decide how to filter rows, then choose which columns to return. Here is a simple example that finds customers with the last name “Smith”:

SELECT cust_id, fname
FROM individual
WHERE lname = 'Smith';

This query returns a relation containing two columns (cust_id, fname) and only the rows where lname matches 'Smith'.

Neighboring topic from relational theory: the WHERE clause corresponds to a selection operation, and the SELECT list corresponds to a projection. SQL’s syntax is different from relational algebra, but the underlying ideas are closely related.

In addition to querying, you will often insert and update data. Here is a simple INSERT example:

INSERT INTO product (product_cd, name)
VALUES ('CD', 'Certificate of Deposit');

If you later need to correct a value, you can use an UPDATE statement:

UPDATE product
SET name = 'Certificate of Deposit'
WHERE product_cd = 'CD';

These statements illustrate a core idea: SQL is both a data manipulation language (DML) and a data definition language (DDL). Over time, the need for portability and consistent behavior drove SQL standardization, which is why you’ll see references to major standards milestones in SQL history in the next lesson.

[1]internet computing model: client/server architectures are described by tiers according to how application logic is distributed. The internet computing model uses a multi-tier design where an application server (middle tier) sits between clients and the database.