En la lección anterior devolvías datos tal como están guardados. Pero una base de datos no guarda el precio con IVA, ni el margen de un producto, ni el importe de una línea de pedido: guarda las piezas mínimas y el resto se calcula al consultarlo. En esta lección aprenderás a construir esas columnas calculadas con expresiones aritméticas y de texto, a ponerles un nombre legible con AS, y a entender —usando el orden lógico de ejecución de 02-01— por qué ese nombre se puede usar en unos sitios de la consulta y en otros no. Aquí aparece además la expresión más importante de todo el curso: cantidad * precio_unitario * (1 - descuento).

1. Alias de columna con AS
2. Cuándo el alias necesita comillas dobles
3. Alias de tabla
4. Columnas calculadas: aritmética sobre columnas
5. La expresión estrella: el importe de una línea de pedido
6. Concatenación de texto: || y CONCAT
7. ROUND para presentar dinero
8. Por qué el alias no funciona en WHERE pero sí en ORDER BY
9. Errores Comunes y Consejos
10. Ejercicios
11. Conclusión

Un alias es el nombre que quieres que tenga una columna en el resultado. Se declara con AS:

Antes de nada, comprobemos por qué hace falta. Sin alias, una expresión no tiene nombre:

?column? es la forma que tiene PostgreSQL de decir "esto no tiene nombre". Un informe con esa cabecera es inservible, y un programa que acceda al resultado por nombre de columna no encontrará nada. Con alias:

(10 primeras de 20 filas.)

La palabra AS es opcional para las columnas. Estas dos líneas son equivalentes:

Aun así, escríbela siempre. Sin AS, olvidar una coma convierte una columna en el alias de la anterior y la consulta se ejecuta sin error dando un resultado equivocado (lo viste en 01-03 y en 02-01):

Un alias es un identificador, así que sigue las reglas de 01-03: sin comillas se pliega a minúsculas y solo admite letras, dígitos y guiones bajos.

Este es el único uso legítimo de las comillas dobles en este curso: alias de presentación destinados a un informe o una exportación. Para cualquier alias que vayas a reutilizar dentro de la consulta, usa snake_case en minúsculas y ahórrate las comillas.

Nota de dialecto: MySQL y SQLite permiten además usar comillas invertidas (`Precio con IVA`) o comillas simples como delimitador de alias. PostgreSQL no: comillas dobles o nada. Escribe siempre la forma estándar.

También las tablas admiten alias, y aquí AS es opcional igualmente:

Con una sola tabla parece un capricho: p.nombre no aporta nada frente a nombre. Su valor aparece en el módulo 3, cuando una consulta combine varias tablas que tienen columnas con el mismo nombre:

Sin los alias p y c, nombre sería ambiguo y PostgreSQL respondería column reference "nombre" is ambiguous. De ahí que en SQL profesional casi todas las consultas lleven alias de tabla.

Convenciones útiles para los alias de tabla:

Una diferencia que sorprende: si pones alias a la tabla, el nombre original deja de estar disponible. Esto falla:

Una columna calculada es una expresión en la lista del SELECT. Se evalúa fila a fila, con los valores de esa fila.

(10 primeras de 20 filas.)

En la resta la escala del resultado es la mayor de las dos, así que el margen sale con dos decimales limpios. En la multiplicación no será así.

(6 primeras de 20 filas.)

Tres cosas que aprender de aquí:

1. Los paréntesis son obligatorios. Sin ellos, precio - coste / precio * 100 se evaluaría como precio - ((coste / precio) * 100), porque * y / tienen más prioridad que - (tabla de precedencia de 01-03). El resultado para el producto 1 sería 12.50 - 62.4 = -49.90. No da error: da un número absurdo.
2. La división es decimal, no entera, porque precio es NUMERIC y no INTEGER. Si las columnas fueran enteras, (precio - coste) / precio daría 0 para todas las filas y luego 0 * 100 = 0. Es el fallo clásico al calcular porcentajes; se resuelve convirtiendo un operando a NUMERIC con CAST (módulo 6).
3. La cola de decimales es fea. PostgreSQL calcula la división NUMERIC con precisión amplia. Para presentarlo hace falta ROUND (sección 7).

(Selección de filas de las 20.)

Aquí stock es INTEGER y precio es NUMERIC(10,2): al mezclar tipos, PostgreSQL promueve el entero a NUMERIC y el resultado conserva dos decimales.

Cuidado con la división entre cero. Si en lugar de stock * precio calcularas algo / stock, el producto 13 (stock 0) haría fallar la consulta entera con ERROR: division by zero. La protección se hace con NULLIF, que se ve en el módulo 6.

En 01-06 quedó fijado que pedidos no tiene columna total y que el importe de una línea es:

Esta expresión va a aparecer en prácticamente todos los módulos que quedan. Escribámosla por primera vez:

(12 primeras de 47 filas.)

Desmontemos la expresión, porque cada pieza importa:

Comprueba la línea 6 a mano: 6 unidades × 1.95 € = 11.70 €; con un 10 % de descuento, 11.70 × 0.90 = 10.53 €. Coincide.

Y fíjate en el cuatro decimales: 10.5300, no 10.53. La cantidad es entera y no aporta escala, precio_unitario aporta 2 y (1 - descuento) otros 2, así que el resultado sale con 4. Aritméticamente es correcto y para sumar es lo que quieres, pero para enseñárselo a alguien hay que redondear.

Seis líneas de las 47 llevan descuento; estos son sus importes exactos:

Ahí hay un detalle revelador: la línea 24 vale 34.0200 € y la devolución del pedido 10 registrada en devoluciones es de 34.02 €. Los datos son coherentes entre tablas, y comprobarlo con una consulta será uno de los ejercicios del módulo 3.

Error frecuente: escribir cantidad * precio_unitario * descuento. Eso calcula el importe descontado, no el importe cobrado. Para la línea 6 daría 1.17 € en lugar de 10.53 €.

El operador estándar de concatenación en SQL es ||:

Puedes concatenar texto con números: PostgreSQL convierte el número a texto automáticamente.

(3 primeras de 20 filas.)

Concatenar cualquier cosa con NULL da NULL. Todo el texto se pierde. Esta es una de las sorpresas más caras de SQL, y TiendaVerde tiene datos para demostrarlo: siete clientes tienen referido_por_id a NULL.

Siete filas con origen vacío, no siete filas con el texto y un hueco. El literal 'Referido por el cliente ' desaparece por completo, porque la regla de los nulos es que cualquier operación con un valor desconocido produce un valor desconocido.

La función CONCAT ignora los NULL y los sustituye por cadena vacía:

(Selección de filas de las 15.)

Ya no se pierde el texto, pero el resultado tampoco es correcto: dice "Referido por el cliente" sin decir cuál. La solución de verdad es sustituir el nulo por un texto sensato con COALESCE, que se estudia en la lección 06-04:

Comparativa para tener a mano:

| Aspecto | a || b | CONCAT(a, b) | |---|---|---| | Estándar SQL | Sí | No (pero muy extendida) | | Con NULL | Devuelve NULL | Trata el NULL como '' | | En MySQL | Por defecto no concatena: || es el OR lógico | Es la forma habitual | | En SQL Server | No existe; se usa + | Existe desde 2012 | | En SQLite | Sí | No existe |

Nota de dialecto importante: en MySQL, 'a' || 'b' devuelve 0, porque ahí || significa OR. Solo se comporta como concatenación si el servidor tiene activado el modo PIPES_AS_CONCAT. Si escribes SQL que deba funcionar en MySQL y PostgreSQL, usa CONCAT.

ROUND(expresión, decimales) redondea a la cantidad de decimales que indiques:

Ahora sí es una tabla presentable. Y con ella ya puedes responder a una pregunta de negocio: el producto con más margen porcentual es el cepillo de dientes de bambú (65.71 %), y el de menos, el aceite de oliva virgen extra (37.60 %) —el producto estrella del catálogo es, precisamente, el que menos margen relativo deja.

Lo mismo para el importe de línea:

(Las 6 líneas con descuento, de las 47.)

Observa la línea 18: el valor exacto es 35.6250 y ROUND lo deja en 35.63. Sobre tipos NUMERIC, PostgreSQL redondea "medio hacia arriba" (alejándose del cero), que es lo que espera cualquier contable.

Regla del curso: calcula con la expresión completa y redondea solo al final, para presentar. Si redondeas cada línea y luego sumas, el total puede diferir en céntimos del total redondeado. Las funciones numéricas (ROUND, CEIL, FLOOR, TRUNC, ABS) se estudian a fondo en la lección 06-02.

Aquí es donde el orden lógico de 02-01 deja de ser teoría. Intenta filtrar por una columna calculada:

La tabla existe, el alias está escrito justo arriba, y aun así el motor dice que esa columna no existe. La explicación está en el diagrama:

Cuando se evalúa WHERE, el paso SELECT todavía no se ha ejecutado, así que el nombre precio_con_iva no se ha creado aún. Cuando se evalúa ORDER BY, sí.

Las dos soluciones para filtrar por una expresión:

Y en ORDER BY el alias funciona sin más (lección 02-05):

(5 primeras de 20 filas.)

Resumen para memorizar:

• Olvidar AS y perder una coma. SELECT nombre precio FROM productos no falla: devuelve los nombres bajo la cabecera precio. Cuenta siempre las columnas del resultado.
• Alias con comillas simples. AS 'Precio' es un error de sintaxis en PostgreSQL. Comillas dobles para identificadores, simples para cadenas.
• Esperar que AS PrecioIVA conserve las mayúsculas. Sin comillas se pliega a precioiva.
• Usar un alias en WHERE. column "..." does not exist. Repite la expresión o usa una subconsulta.
• Olvidar los paréntesis en el margen porcentual. precio - coste / precio * 100 no da error y devuelve números sin sentido.
• Confundir el descuento con el importe descontado. El importe cobrado es cantidad * precio_unitario * (1 - descuento); sin el 1 - calculas justo lo contrario.
• Concatenar con || sobre columnas que pueden ser nulas. Pierdes toda la cadena. Usa CONCAT o, mejor, COALESCE (módulo 6).
• Redondear demasiado pronto. Redondea solo en la capa de presentación; los cálculos intermedios, con toda la precisión.
• Consejo: nombra los alias como columnas reales. snake_case, en minúsculas, descriptivos: precio_con_iva, margen_pct, importe. Los alias "bonitos" con comillas, solo para el informe final.
• Consejo: valida la expresión con SELECT sin FROM. SELECT 8 * 1.95 * (1 - 0.15); te confirma en un segundo si la fórmula es la que crees.

Escribe una consulta sobre productos que devuelva, con alias legibles: el nombre del producto, su precio, su margen unitario en euros y su margen porcentual redondeado a un decimal. Explica por qué los paréntesis del margen porcentual son imprescindibles.

Sobre empleados, construye una única columna de texto llamada ficha con este formato exacto: Apellidos, Nombre (Puesto) - Ciudad. Por ejemplo: Alcázar Vives, Rosa (Directora general) - Valencia.

Sobre lineas_pedido, devuelve el id de la línea, el pedido al que pertenece, el importe bruto (sin aplicar descuento), el importe descontado en euros y el importe final cobrado, los tres redondeados a dos decimales. Comprueba tus resultados con las seis líneas que tienen descuento.

Solución 1

(10 primeras de 20 filas.)

Razonamiento sobre los paréntesis. La precedencia de operadores de 01-03 dice que * y / se evalúan antes que -. Sin paréntesis, precio - coste / precio * 100 significa precio - ((coste / precio) * 100). Para el producto 1: 12.50 - ((7.80/12.50) * 100) = 12.50 - 62.40 = -49.90. Un margen negativo del -49.90 en un producto que gana 4.70 € por unidad. La consulta se ejecuta sin ningún aviso: es un error silencioso, el peor tipo.

Solución 2

Razonamiento. Se alternan columnas y literales de texto: los literales van entre comillas simples y llevan dentro los espacios, comas y paréntesis del formato. Han salido las 8 filas completas porque en esta tabla ninguna de las cuatro columnas usadas es nula. Si ciudad lo fuera —y podría serlo, porque la columna admite nulos—, esa fila devolvería NULL entera. En una consulta destinada a producción convendría blindarla con COALESCE(ciudad, 'Sin asignar'), que verás en 06-04.

Solución 3

Las seis líneas con descuento, de las 47 que devuelve la consulta:

Razonamiento. Las tres columnas comparten la base cantidad * precio_unitario; lo que cambia es qué se hace con descuento: multiplicar por descuento da lo que el cliente se ahorra, multiplicar por (1 - descuento) da lo que paga. La comprobación de que la fórmula es correcta es que descuento_eur + importe_final = importe_bruto en todas las filas. En la línea 18 hay una diferencia de un céntimo aparente (1.88 + 35.63 = 37.51 ≠ 37.50): es el efecto de redondear cada columna por separado, ya que los valores exactos son 1.8750 y 35.6250. Es exactamente el motivo por el que se redondea al final y no en cada paso intermedio.

Ahora tus consultas no solo leen: calculan.

• Un alias con AS da nombre a cualquier columna o expresión; sin él verás ?column?. Escribe AS siempre, aunque sea opcional.
• Las comillas dobles en un alias solo son necesarias si contiene espacios, símbolos o mayúsculas que quieras conservar: úsalas únicamente para alias de presentación.
• Los alias de tabla parecen superfluos con una sola tabla y serán obligatorios en el módulo 3.
• Sabes construir columnas calculadas: precio con IVA, margen en euros y margen porcentual, con los paréntesis en su sitio y sin caer en la división entera.
• Dominas la expresión que sostiene todo el curso: cantidad * precio_unitario * (1 - descuento), y entiendes por qué el descuento es una fracción y por qué el resultado sale con cuatro decimales.
• Concatenas texto con || y conoces su trampa: cualquier operando NULL anula toda la cadena. CONCAT la evita, COALESCE (módulo 6) la resuelve bien.
• Presentas importes con ROUND(expresión, 2), redondeando solo al final.
• Y, sobre todo, entiendes por el orden lógico de ejecución por qué un alias no existe todavía en WHERE y sí en ORDER BY.

En la siguiente lección, Filtrando datos con WHERE, añadirás el paso 2 del diagrama: dejarás de traer las 20 filas de productos o las 47 de lineas_pedido y empezarás a pedir solo las que cumplen una condición. Con comparaciones sobre números, texto y fechas, y con AND, OR, NOT y unos paréntesis que, otra vez, marcarán la diferencia entre un resultado correcto y uno silenciosamente equivocado.