Cerraste el módulo 1 con la base de datos de TiendaVerde cargada y verificada, y con una promesa: la primera consulta real estaba a una lección de distancia. Ha llegado. En esta lección aprenderás la instrucción más importante de SQL, la que usarás el 90 % de las veces que te sientes delante de una base de datos: SELECT. Verás cómo pedir columnas concretas, por qué SELECT * es cómodo para explorar pero peligroso en producción, qué es realmente el conjunto de resultados que te devuelve el motor y —lo más importante a medio plazo— en qué orden lógico ejecuta PostgreSQL las cláusulas de una consulta, que no es el orden en el que las escribes. Ese último punto parece teórico hoy y será la clave para entender los módulos 4 y 7.

1. La consulta mínima: SELECT ... FROM ...
2. Seleccionar columnas concretas
3. SELECT *: cuándo sí y por qué en producción no
4. El orden de las columnas lo decide el SELECT
5. SELECT sin FROM: SQL como calculadora
6. Qué es realmente el conjunto de resultados
7. El orden lógico de ejecución de una consulta
8. Leer resultados en psql y el modo expandido \x
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

Una consulta de lectura necesita, como mínimo, dos cláusulas:

Léela en voz alta al revés y entenderás mejor lo que hace el motor: "de la tabla categorias, dame la columna nombre".

En la jerga del modelo relacional que viste en 01-05, SELECT hace una proyección (elegir columnas) y, cuando añadamos WHERE en la lección 02-03, haremos también una selección (elegir filas). Que la palabra clave se llame SELECT y haga la proyección es una de las pequeñas incoherencias históricas de SQL; conviene saberlo para no confundirse al leer literatura académica.

Fíjate en que no le has dicho a PostgreSQL cómo recorrer la tabla, ni en qué fichero está, ni si conviene usar un índice. Solo has descrito el qué. Eso es el carácter declarativo del lenguaje que vimos en 01-01.

Para pedir varias columnas se separan por comas:

20 filas. Exactamente las 20 que cargaste en 01-06: SELECT sin filtro devuelve todas las filas de la tabla, y proyecta solo las columnas que has nombrado. Ni coste, ni stock, ni activo, ni fecha_alta aparecen: no los has pedido.

Detalles de escritura que ya conoces de 01-03 y que aquí se aplican:

• La coma va entre columnas, nunca detrás de la última. SELECT id, nombre, FROM productos da syntax error at or near "FROM".
• Poner una columna por línea no es capricho: cuando la lista crezca a quince columnas, agradecerás poder añadir o quitar una sin reescribir la línea entera.
• Los nombres deben existir. Si escribes SELECT precio_venta FROM productos, PostgreSQL responde column "precio_venta" does not exist. Un \d productos te saca de dudas en un segundo.

El asterisco significa "todas las columnas de la tabla, en el orden en que se definieron":

Es cómodo, y para explorar una tabla que no conoces es lo primero que se escribe. El problema aparece cuando ese * acaba dentro de una aplicación, un informe o una vista.

Regla del curso: SELECT * para explorar en psql; lista explícita de columnas en cualquier consulta que vayas a guardar, versionar o ejecutar más de una vez.

Hay una variante intermedia que sí es habitual y correcta: SELECT tabla.* en consultas con varias tablas, para decir "todas las columnas de esta tabla". La verás en el módulo 3.

El resultado no tiene por qué respetar el orden físico de la tabla. Manda tu lista:

Y nada te impide repetir una columna, aunque rara vez sea útil:

Devuelve tres columnas, dos de ellas llamadas id. PostgreSQL lo permite; los clientes y los lenguajes de programación que acceden por nombre, no siempre. Es un aviso de que en cuanto haya nombres repetidos harán falta alias, que es justo el tema de la lección siguiente.

En PostgreSQL la cláusula FROM es opcional. Sin ella, SELECT evalúa expresiones y devuelve una única fila:

Esa cabecera ?column? significa "no sé cómo llamar a esto": la expresión no tiene nombre. Se arregla con un alias (lección 02-02).

Ejemplos que usarás a diario para probar cosas antes de meterlas en una consulta grande:

Tres cosas que ya se ven aquí y que reaparecerán:

1. current_date devuelve la fecha del día en que ejecutes la consulta; el valor de arriba es solo un ejemplo.
2. 12.50 * 1.21 da 15.1250, con cuatro decimales. PostgreSQL suma las escalas de los operandos al multiplicar NUMERIC. Para presentar dinero habrá que redondear (lección 02-02).
3. 3 * 12.50 * (1 - 0.05) es el cálculo del importe de la línea 18 de lineas_pedido, con los números escritos a mano. En la lección siguiente lo escribirás con columnas en lugar de literales.

Nota de dialecto: Oracle exige un FROM, y por eso allí se escribe SELECT 2+2 FROM dual;. MySQL, SQL Server, SQLite y PostgreSQL admiten SELECT sin FROM.

Lo que devuelve una consulta se llama conjunto de resultados (result set) y, conceptualmente, es una relación: una tabla temporal, sin nombre, que existe solo mientras dura la consulta. De ahí se derivan tres propiedades que conviene interiorizar hoy:

1. Es una tabla como cualquier otra. Tiene columnas con nombre y tipo, y filas. Por eso podrá usarse como origen de otra consulta (subconsultas en FROM, módulo 7) o combinarse con otra relación (UNION, módulo 3).
2. No modifica nada. SELECT es una operación de solo lectura: por muchas veces que la ejecutes, la tabla original no cambia. Modificar datos es el módulo 5.
3. No tiene orden garantizado. Esta es la que más sorprende.

Sobre el tercer punto: en el resultado de la sección 2 los productos salieron ordenados por id, del 1 al 20. Parece que la tabla "está ordenada". No lo está. Ese orden es un efecto colateral de que las filas se insertaron seguidas y PostgreSQL las leyó en orden físico. En cuanto la tabla crezca, se actualicen filas, entre en juego un índice o el motor use varios procesos en paralelo, el orden puede cambiar sin aviso y sin que nada falle.

La regla es tajante y no admite excepciones:

Si el orden importa, escribe ORDER BY. Si no lo escribes, no tienes derecho a esperar ningún orden concreto.

La cláusula ORDER BY es la lección 02-05. Hasta entonces, cuando en esta lección o en la siguiente veas resultados "ordenados por id", entiende que es el orden que probablemente verás, no el que el motor te promete.

Escribes una consulta en un orden y el motor la resuelve en otro. Entender esa diferencia es lo que después hace evidentes cosas que de otro modo parecen arbitrarias (por qué un alias funciona en ORDER BY pero no en WHERE, por qué HAVING existe además de WHERE, por qué una subconsulta puede ver ciertas columnas y otras no).

Orden en que se escribe:

Orden en que se ejecuta lógicamente:

De momento solo usas los pasos 1 y 3, así que el diagrama parece exagerado. Guárdalo: iremos añadiendo cláusulas a este mismo esquema en cada lección del módulo, y en el módulo 4 le incorporaremos GROUP BY y HAVING.

Dos consecuencias que ya puedes anticipar:

• Como WHERE se ejecuta antes que SELECT, cuando llegue el momento de filtrar no podrás usar en WHERE un nombre inventado en el SELECT: todavía no existe.
• Como ORDER BY se ejecuta después de SELECT, allí sí podrás usarlo.

Un matiz importante: esto es el orden lógico, el que define el significado de la consulta. El plan real de ejecución que elige el optimizador puede ser muy distinto (leer un índice, filtrar mientras lee, parar antes de tiempo), siempre que el resultado sea el mismo que el del orden lógico. Los planes reales se estudian en el módulo 8 con EXPLAIN.

Cuando ejecutas una consulta en psql ves algo así:

Piezas de esa salida:

Los booleanos se imprimen como t y f, no como true/false. En este curso los escribiremos como true/false en las tablas de resultados por legibilidad.

Cuando una fila tiene muchas columnas o textos largos, la salida se desmonta y se vuelve ilegible. Para eso está el modo expandido:

Cada fila pasa a ocupar un bloque vertical. Se ve perfectamente que el cliente 1 tiene referido_por_id vacío (es NULL: llegó por su cuenta) y el cliente 2 fue referido por el cliente 1.

\x alterna entre activado y desactivado; \x auto deja que psql decida según el ancho del terminal, y es la opción más cómoda para el día a día.

Otros metacomandos que te ahorrarán tiempo en este módulo:

Cierra la lección practicando la proyección sobre las tres tablas que más usarás.

Quiénes son los clientes y de dónde son:

El equipo, con su jerarquía en bruto:

Ahí está el NULL de Rosa Alcázar Vives, la única sin jefe. Verlo como una celda vacía es tu primer contacto práctico con los nulos: el módulo 4 les dedica una lección entera.

El estado de los pedidos:

Observa que cliente_id es un número, no un nombre. Para saber que el pedido 10 es de Camille Dubois hay que ir a clientes, y eso exige combinar dos tablas: es exactamente lo que hace el JOIN del módulo 3. Hasta entonces trabajaremos siempre con una tabla cada vez.

• Coma sobrante antes de FROM. SELECT id, nombre, FROM productos → syntax error at or near "FROM". El error señala FROM, pero el fallo está en la coma anterior (regla del "mira el token anterior" de 01-03).
• Coma que falta entre columnas. SELECT nombre precio FROM productos no da error: PostgreSQL entiende precio como alias de nombre y devuelve una sola columna llamada precio con los nombres de los productos. Es un fallo silencioso; cuenta siempre las columnas del resultado.
• column "..." does not exist. Casi siempre es una errata o una columna que está en otra tabla. \d tabla antes de reescribir a ciegas.
• Confundir comillas. SELECT "nombre" FROM productos funciona (identificador en minúsculas); SELECT 'nombre' FROM productos devuelve 20 filas con el texto literal nombre. No es lo mismo.
• Suponer que el resultado viene ordenado. Funciona hoy con 20 filas y falla el día que la tabla tenga un millón. ORDER BY o nada.
• Dejar SELECT * en el código. Úsalo para explorar, sustitúyelo por la lista de columnas en cuanto la consulta sea definitiva.
• Consejo: mira siempre el recuento de filas. Si esperabas 20 y psql dice (0 filas), has aprendido algo antes de leer una sola celda.
• Consejo: prueba las expresiones sin FROM. SELECT 3 * 12.50 * (1 - 0.05); valida el cálculo en un segundo, sin ruido de tablas.
• Consejo: activa \x auto. Es la diferencia entre leer una fila de clientes y pelearse con el terminal.

Escribe una consulta que devuelva el nombre, el país y el email de todos los proveedores. Después responde: ¿cuántas filas devuelve y por qué no hace falta ningún filtro para obtenerlas todas?

Sobre empleados, escribe una consulta que muestre las columnas en este orden exacto: puesto, apellidos, nombre, ciudad. Justifica por qué el resultado no coincide con el orden en que las columnas están definidas en la tabla.

Sin usar ninguna tabla, calcula con SELECT estas tres cosas y explica el resultado:

1. El precio con IVA (21 %) del producto 15 (Té verde matcha ceremonial, 22.00 €).
2. El importe de la línea 27 de lineas_pedido: 8 unidades a 1.95 € con un descuento de 0.15.
3. El margen bruto del producto 6 (precio 18.90, coste 9.50).

Solución 1

Devuelve 5 filas. Una consulta sin WHERE no descarta ninguna fila: el paso 2 del orden lógico simplemente no existe, así que todo lo que sale de FROM llega a SELECT. Fíjate en que el proveedor 5 aparece aunque tenga activo = FALSE: nada lo excluye. Filtrarlo será tarea de la lección 02-03.

Solución 2

El razonamiento: la tabla define las columnas como id, nombre, apellidos, puesto, jefe_id, salario, fecha_contratacion, ciudad, pero ese orden solo lo usa SELECT *. Cuando enumeras columnas, el orden del resultado es el de tu lista, porque la proyección construye una relación nueva con la forma que tú decides. Es la misma razón por la que puedes omitir columnas o repetirlas.

Solución 3

Tres observaciones sobre el razonamiento:

1. 22.00 * 1.21 da 26.6200, no 26.62. Al multiplicar dos NUMERIC, PostgreSQL suma las escalas: dos decimales por dos decimales dan cuatro. Para un informe habrá que redondear.
2. El descuento es una fracción, así que 0.15 es el 15 % y el factor que se aplica es (1 - 0.15) = 0.85. Escribir 8 * 1.95 * 0.15 daría el descuento, no el importe. Es el error de interpretación más frecuente con esta base de datos.
3. La resta 18.90 - 9.50 mantiene dos decimales, porque en la suma y la resta la escala del resultado es la mayor de las dos, no la suma.

(Sí, hemos usado AS antes de tiempo: sin él las tres columnas se llamarían ?column?. Es la primera cláusula de la lección siguiente.)

Ya sabes interrogar una tabla:

• La consulta mínima es SELECT columnas FROM tabla;: FROM dice de dónde salen las filas y SELECT qué columnas se proyectan.
• SELECT * sirve para explorar, pero en producción se sustituye por la lista explícita de columnas: contrato estable, menos tráfico y mejores planes de ejecución.
• El orden de las columnas del resultado lo decides tú con tu lista, no la definición de la tabla.
• SELECT sin FROM convierte a PostgreSQL en una calculadora para probar expresiones antes de integrarlas en una consulta.
• El conjunto de resultados es una relación temporal de solo lectura y sin orden garantizado: si el orden importa, ORDER BY.
• Conoces el orden lógico de ejecución FROM → WHERE → SELECT → ORDER BY → LIMIT, que iremos completando en cada lección de este módulo.
• Sabes leer la salida de psql, contar filas y usar el modo expandido \x cuando las filas son anchas.

En la próxima lección, Alias, expresiones y columnas calculadas, dejarás de limitarte a devolver lo que hay guardado y empezarás a calcular: precios con IVA, márgenes, márgenes porcentuales y el importe de una línea de pedido, la expresión que te acompañará durante todo el curso. De paso pondrás nombre decente a esas columnas con AS y descubrirás, gracias al orden lógico que acabas de aprender, por qué un alias funciona en unos sitios y en otros no.