Errores comunes al trabajar con alias en SQL y cómo evitarlos (guía para principiantes)

Usar alias en SQL parece un detalle menor, pero es clave para escribir consultas claras, mantenibles y profesionales. Sin embargo, también es una de las fuentes de errores más habituales cuando empezamos: alias que “desaparecen”, encabezados confusos, columnas ambiguas o subconsultas sin nombre.

En esta guía te explico, paso a paso y desde cero, los errores más comunes al usar alias en SQL y cómo solucionarlos. Incluye ejemplos ejecutables, tablas de resultados y un checklist final para que revises tus consultas antes de publicarlas o compartirlas.

Si necesitás repasar el concepto base, acá tenés la definición y sintaxis de Alias en SQL y la instrucción SELECT.

1) Recordatorio rápido: ¿qué es un alias?

Un alias es un nombre temporal que le das a una columna o a una tabla dentro de una consulta. No modifica la base de datos; solo renombra en el contexto de la consulta actual:

-- Alias de columna
SELECT precio * cantidad AS total_linea
FROM ventas;

-- Alias de tabla
SELECT c.nombre, p.total
FROM clientes AS c
JOIN pedidos  AS p ON p.cliente_id = c.id;

Con esto en mente, vayamos a los errores típicos.

2) Error: usar el alias en WHERE (no existe todavía)

Síntoma: “Column not found” o resultados inesperados.
Causa: SQL evalúa la consulta en un orden lógico. Simplificado:

1. FROM / JOIN
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY
7. LIMIT / OFFSET

El alias se crea en SELECT. Por eso, no existe cuando se evalúa WHERE.

Incorrecto:

SELECT precio * cantidad AS total
FROM ventas
WHERE total > 100;  -- ❌ 'total' aún no existe

Soluciones correctas:

A) Repetir la expresión

SELECT precio * cantidad AS total
FROM ventas
WHERE (precio * cantidad) > 100;  -- ✅

B) Usar una subconsulta/CTE (recomendado si la expresión es larga)

WITH base AS (
  SELECT precio * cantidad AS total
  FROM ventas
)
SELECT *
FROM base
WHERE total > 100;                 -- ✅ ahora sí existe

Cuando tengas dudas sobre el orden de evaluación, revisá también las entradas de WHERE y ORDER BY.

3) Error: alias ambiguos o duplicados (no se sabe qué es cada cosa)

Síntoma: encabezados poco claros en el resultado o columnas que “se pisan”.
Causa: asignar el mismo alias a dos columnas diferentes o usar alias crípticos.

Incorrecto:

SELECT
  SUM(total) AS total,
  MAX(total) AS total   -- ❌ dos alias iguales
FROM pedidos;

Correcto (alias únicos y semánticos):

SELECT
  SUM(total) AS ventas_totales,
  MAX(total) AS venta_maxima
FROM pedidos;            -- ✅ cada columna “cuenta” qué es

Consejo de estilo: preferí snake_case en español: ventas_ciudad, clientes_activos, total_linea. Eso facilita reportes y dashboards.

4) Error: olvidar el alias en subconsultas del FROM (alias obligatorio)

Síntoma: error de sintaxis (“subquery in FROM must have an alias”).
Causa: una subconsulta en FROM se comporta como una tabla y necesita nombre.

Incorrecto:

SELECT c.nombre, t.ventas
FROM clientes c
JOIN (SELECT cliente_id, SUM(total) AS ventas
      FROM pedidos
      GROUP BY cliente_id)        -- ❌ falta nombre del bloque
  ON t.cliente_id = c.id;

Correcto:

SELECT c.nombre, agg.ventas
FROM clientes c
JOIN (
  SELECT cliente_id, SUM(total) AS ventas
  FROM pedidos
  GROUP BY cliente_id
) AS agg                          -- ✅ ahora la “tabla” tiene nombre
  ON agg.cliente_id = c.id;

Si la subconsulta crece, subila a un CTE con WITH, que es más legible.

5) Error: no calificar columnas con alias de tabla (ambigüedad en JOIN)

Síntoma: “column reference is ambiguous” o, peor, ¡resultados incorrectos!
Causa: dos tablas tienen la misma columna (id, fecha, total), y no especificás de cuál querés leer.

Incorrecto:

SELECT id, fecha
FROM clientes c
JOIN pedidos  p ON c.id = p.cliente_id;   -- ❌ ¿id/fecha de quién?

Correcto:

SELECT c.id       AS cliente_id,
       p.id       AS pedido_id,
       p.fecha    AS fecha_pedido
FROM clientes c
JOIN pedidos  p ON c.id = p.cliente_id;   -- ✅ columnas calificadas

Regla simple: en consultas con JOIN, siempre escribí c.columna, p.columna. El extra de tecleo ahorra bugs.

6) Error: confiar en alias en GROUP BY/HAVING (portabilidad limitada)

Síntoma: funciona en un motor, falla en otro.
Causa: algunos SGBD (como MySQL) permiten referirse a alias de SELECT en HAVING o incluso en GROUP BY. No es estándar y afecta la portabilidad.

Ejemplo que puede fallar:

SELECT cliente_id, SUM(total) AS ventas
FROM pedidos
GROUP BY cliente_id
HAVING ventas > 1000;            -- ⚠️ MySQL lo permite, otros no

Versión portable:

SELECT cliente_id, SUM(total) AS ventas
FROM pedidos
GROUP BY cliente_id
HAVING SUM(total) > 1000;        -- ✅ compatible con todos

Alternativa limpia: mover el cálculo a una subconsulta/CTE y filtrar afuera:

WITH agg AS (
  SELECT cliente_id, SUM(total) AS ventas
  FROM pedidos
  GROUP BY cliente_id
)
SELECT *
FROM agg
WHERE ventas > 1000;             -- ✅ ‘ventas’ existe en esta etapa

Si necesitás repasar, mirá GROUP BY y ORDER BY.

7) Error: usar alias con palabras reservadas o con espacios sin comillas

Síntoma: error de sintaxis o comportamiento extraño.
Causa: algunos alias chocan con palabras clave (user, order, group, rank) o contienen espacios/acentos.

Incorrecto (puede fallar):

SELECT SUM(total) AS order
FROM pedidos;                    -- ❌ ‘order’ es palabra reservada

Correcto:

SELECT SUM(total) AS ventas_totales
FROM pedidos;                    -- ✅ alias claro y seguro

Si realmente necesitás espacios, comillá:

• Estándar / PostgreSQL / Oracle: "Ventas totales"
• SQL Server: [Ventas totales]
• MySQL: comillas dobles (según sql_mode) o backticks: `Ventas totales`

Aun así, la mejor práctica es evitar espacios y acentos en alias.

8) Error: alias que describen la técnica y no el significado

Síntoma: el lector ve cómo se hizo, pero no qué representa.
Causa: poner alias como concat_nombre_apellido o sum_total en vez de nombres útiles para el negocio.

Incorrecto:

SELECT CONCAT(nombre, ' ', apellido) AS concat_nombre_apellido
FROM usuarios;

Correcto (habla el idioma del reporte):

SELECT CONCAT(nombre, ' ', apellido) AS nombre_completo
FROM usuarios;

Preguntate siempre: “¿Qué título quiero ver en el Excel/Looker/Power BI?”.

9) Error: alias demasiado cortos o inconsistentes en tablas

Síntoma: consultas difíciles de leer; confusión en revisiones de código.
Causa: usar a, b, c sin patrón, o cambiar el alias de la misma tabla en bloques distintos.

Ejemplo confuso:

SELECT a.nombre, b.total
FROM clientes a
JOIN pedidos  b ON b.cliente_id = a.id;   -- ❌ ¿qué era ‘a’? ¿qué era ‘b’?

Mejor:

SELECT c.nombre, p.total
FROM clientes c
JOIN pedidos  p ON p.cliente_id = c.id;   -- ✅ convención: c = clientes, p = pedidos

Establecé una guía de estilo y mantenela: c=clientes, p=pedidos, e=empleados, etc.

10) Error: subconsulta en FROM sin alias interno para columnas

Síntoma: afuera no sabés cómo referirte a los campos.
Causa: no dar alias a las columnas calculadas dentro de la subconsulta.

Incorrecto:

SELECT t.total
FROM (
  SELECT SUM(total)     -- ❌ sin alias claro
  FROM pedidos
) AS t;

Correcto:

SELECT t.ventas_totales
FROM (
  SELECT SUM(total) AS ventas_totales
  FROM pedidos
) AS t;

11) Error: subconsulta escalar que devuelve más de una fila

Síntoma: “more than one row returned by a subquery used as an expression”.
Causa: la subconsulta en la lista SELECT debe devolver un solo valor por fila.

Incorrecto:

SELECT c.nombre,
       (SELECT total FROM pedidos p WHERE p.cliente_id = c.id) AS total -- ❌ puede haber varios
FROM clientes c;

Soluciones:

• Agregar agregación (MAX, SUM) o LIMIT 1/TOP 1/FETCH FIRST 1 ROW ONLY según motor.

SELECT c.nombre,
       (SELECT SUM(total) FROM pedidos p WHERE p.cliente_id = c.id) AS ventas_cliente  -- ✅
FROM clientes c;

12) Error: mezclar alias con posiciones en ORDER BY/GROUP BY

Síntoma: consultas frágiles; cambiás el orden de las columnas y se rompen.
Causa: usar posiciones (ORDER BY 3) en lugar de nombres.

Incorrecto:

SELECT ciudad, SUM(total) AS ventas
FROM pedidos
GROUP BY 1              -- ❌ frágil: ¿qué era el 1?
ORDER BY 2 DESC;        -- ❌ frágil: ¿qué era el 2?

Correcto:

SELECT ciudad, SUM(total) AS ventas
FROM pedidos
GROUP BY ciudad          -- ✅ claro y estable
ORDER BY ventas DESC;    -- ✅ usa alias explícito

13) Error: depender de comportamientos no estándar de un SGBD

Síntoma: tu consulta funciona en MySQL, pero no en PostgreSQL/SQL Server/Oracle.
Causa: cada motor tiene detalles distintos (uso de alias en HAVING, comillas, LIMIT vs TOP vs FETCH FIRST, etc.).

Recomendación:

• Escribí SQL estándar cuando puedas.
• Si necesitás algo específico, documentalo en el comentario de la consulta.
• Probá tus consultas en el motor objetivo y, si tu audiencia es amplia, indicá equivalencias.

14) Errores y soluciones resumidos (tabla de consulta rápida)

15) Caso completo: “clientes con total de su ciudad” (alias bien usados)

Objetivo: mostrar el nombre del cliente y cuántos clientes hay en su misma ciudad. Esto combina JOIN, subconsulta en FROM y alias claros.

SELECT cl.nombre,
       agg.total_clientes
FROM clientes AS cl
JOIN (
  SELECT ciudad,
         COUNT(*) AS total_clientes
  FROM clientes
  GROUP BY ciudad
) AS agg
  ON cl.ciudad = agg.ciudad
ORDER BY agg.total_clientes DESC, cl.nombre;

Salida (ejemplo):

Qué está bien aquí:

• Alias de tabla consistentes: cl (clientes), agg (agregado).
• Alias de columna semántico: total_clientes.
• ORDER BY usa alias válidos.
• Subconsulta en FROM con alias.

Si querés profundizar en subconsultas, mirá SUBQUERY.

16) Guía de estilo rápida para alias (aplícalo en tus proyectos)

• Estilo: snake_case, minúsculas, sin acentos ni espacios.
• Alias de tabla: cortos y con sentido (c, p, e).
• Alias de columna: de negocio, no técnicos (ventas_mes, ticket_promedio, nombre_completo).
• Evitar palabras reservadas (user, order, group, rank).
• Consistencia: si c es clientes en un bloque, usá c en todo el archivo/proyecto.
• Portabilidad: no dependas de trucos del motor si querés compartir el SQL.

17) Checklist antes de ejecutar/compartir tu consulta

• ¿Las subconsultas en FROM tienen alias?
• ¿Evitaste usar alias de SELECT en WHERE?
• ¿Calificaste columnas en JOIN (c.col) para evitar ambigüedad?
• ¿Los alias son únicos, claros y consistentes?
• ¿Evitaste palabras reservadas y espacios sin comillas?
• ¿Usaste HAVING (o CTE) para filtrar agregados en vez de alias en WHERE?
• ¿Tu subconsulta escalar garantiza 1 valor por fila?
• ¿Tu ORDER BY usa nombres/alias, no posiciones (“ORDER BY 2”)?

Cierre

Los alias son una herramienta pequeña con un gran impacto en la calidad de tu SQL. Evitá los errores de esta guía y adoptá un estilo consistente: alias de tablas cortos y estables, alias de columnas claros y de negocio, subconsultas siempre con nombre, nada de alias en WHERE, y cuidado con HAVING/GROUP BY según el motor. Con estas prácticas, tus consultas van a ser más legibles, portables y fáciles de mantener para vos y para todo tu equipo.

📚 Artículos relacionados

• Cómo usar alias en SQL para simplificar consultas SELECT con ejemplos
  Guía paso a paso para principiantes donde aprenderás a usar alias en combinación con SELECT, con ejemplos prácticos y resultados claros.
• Buenas prácticas para nombrar columnas y tablas con alias en SQL
  Recomendaciones claras y ejemplos detallados para elegir alias descriptivos, consistentes y fáciles de entender en tus consultas SQL.
• Cómo aplicar alias en subconsultas SQL para mejorar la legibilidad
  Explicación detallada y práctica de cómo usar alias en subconsultas para que las consultas sean más claras, organizadas y fáciles de mantener.
• Uso de alias en SQL con funciones de agregación como COUNT y SUM
  Ejemplos prácticos y explicaciones para aplicar alias en funciones de agregación y generar reportes legibles y profesionales.