SELECT and FROM: choose what information we want to read
A table may contain dozens of columns, but a query rarely needs to display all of them. Sometimes we look for a client’s name and email; other times we need your identifier to match it with an order.
Before filtering or combining data, we must decide two things: where it comes from and what part of it we want to recover.
The idea
FROM identifies the data source. SELECT defines the columns or expressions that will appear in the result. A column is a field defined by the table; an expression is a value or calculation that SQL Server can evaluate to produce a result column.
Although we write SELECT first, it is best to read the query this way:
From this table, select these columns.
Syntax
SELECT
alias.Columna1,
alias.Columna2
FROM dbo.Tabla AS alias;
The alias does not modify the table. Just provide a short name to refer to within the query.
We can also assign an alias to a calculated column:
SELECT
Precio * Cantidad AS Importe
FROM dbo.PedidoDetalle;
Example
Suppose that dbo.Cliente contains, among others, these columns. NULL marks a value as unknown or unavailable; it does not represent zero or an empty string.
| ClientId | Name | RegistrationDate | Active | |
|---|---|---|---|---|
| 1 | Ana Torres | ana@example.test | 2026-01-12 09:15 | 1 |
| 2 | Bruno Diaz | bruno@example.test | 2026-02-03 11:40 | 1 |
| 3 | Carla Ruiz | NULL |
2026-02-18 16:05 | 1 |
If we only need to identify the customer and show their contact information:
SELECT
c.IdCliente,
c.Nombre,
c.Correo
FROM dbo.Cliente AS c;
How to read the result
| ClientId | Name | |
|---|---|---|
| 1 | Ana Torres | ana@example.test |
| 2 | Bruno Diaz | bruno@example.test |
| 3 | Carla Ruiz | NULL |
The query did not modify the table or delete its other columns. It only built a result that contains the three requested columns.
Carla’s NULL value is also preserved. SELECT displays the stored value; it does not replace or discard it by itself.
What should be checked
SELECT * requests all available columns. This may be convenient during a quick scan, but has consequences when it remains in application code:
- transfers information that may not be used;
- makes it difficult to recognize what the query depends on;
- can change the result when someone adds or reorders columns;
- increases the chance of receiving repeated names when combining tables.
Choosing the columns explicitly better documents the intent. SELECT * is not incorrect in all contexts, but it should be a decision and not a habit.
The order of the rows is also not guaranteed by SELECT. If the result needs a specific order, we must declare it with ORDER BY.