Dialectos de SQL: el 90% que es igual y el 10% que te tira la prueba técnica

SQL tiene más de cincuenta años. Nació en los laboratorios de IBM a principios de los setenta, se estandarizó por primera vez en 1986 con el estándar ANSI SQL, y desde entonces cada fabricante de bases de datos ha ido añadiendo sus propias extensiones, atajos y particularidades. Exactamente igual que el español: la gramática es la misma en Madrid, en Ciudad de México y en Buenos Aires, pero las expresiones cambian lo suficiente como para que te pierdas un momento si no estás atento. Un SELECT, un WHERE, un GROUP BY y un JOIN funcionan igual en todos los motores. Pero la forma de extraer el mes de una fecha, de concatenar dos textos, de limitar las filas o de rellenar un valor nulo tiene diferencias que, si no las conoces, hacen que tu consulta falle sin que entiendas por qué.

Esta lección no pretende que memorices la sintaxis de cinco motores. Pretende que sepas qué cambia, que reconozcas al vuelo el tipo de fallo que provoca un cambio de dialecto, y que tengas un sistema para resolverlo en diez minutos con la documentación oficial delante. Porque en tu carrera vas a cambiar de motor: del DuckDB de prácticas al Redshift de tu primer empleo, del Redshift al BigQuery del siguiente, y quizá al Snowflake del tercero. Si cada vez tienes que reaprender SQL desde cero, algo va muy mal. Si cada vez solo tienes que consultar un puñado de diferencias, vas bien.

La analogía más útil es un coche de alquiler. Todos tienen volante, pedales, marchas y retrovisores. Si sabes conducir, alquilas un coche de cualquier marca y arrancas en cinco minutos. Pero el mando del limpiaparabrisas está en un sitio distinto, el manos libres se conecta de otra forma y la palanca del intermitente puede estar al otro lado. No necesitas estudiar cada coche: necesitas saber dónde mirar cuando algo no está donde esperabas. Con SQL pasa exactamente lo mismo. Los mandos principales son universales; lo que cambia son los botones secundarios.

### Los seis motores que te vas a encontrar

El mercado de almacenes analíticos, es decir, las bases de datos preparadas para responder preguntas sobre muchos datos a la vez, se ha concentrado en un puñado de motores que aparecen una y otra vez en las ofertas de empleo. No necesitas dominarlos todos, pero sí saber que existen y qué los diferencia en el uso diario. Estos son los seis que verás con más frecuencia como analista:

• ▹PostgreSQL — la base de datos relacional de código abierto más popular del mundo. Muchas empresas la usan directamente como almacén analítico hasta que crecen lo suficiente para necesitar algo mayor. Su dialecto es el más cercano al estándar ANSI, así que es una buena vara de medir.
• ▹BigQuery (Google) — el almacén en la nube de Google. Pagas por los datos que escanea cada consulta, no por el tiempo que tarda. Su dialecto tiene diferencias notables en el manejo de fechas (el orden de los argumentos cambia) y en cómo se escriben algunas subconsultas.
• ▹Snowflake — el almacén en la nube independiente, que no pertenece a ninguna de las grandes tecnológicas. Muy común en empresas medianas y grandes. Su dialecto está cerca del estándar, pero tiene funciones propias para fechas y para trabajar con JSON.
• ▹Redshift (Amazon) — el almacén en la nube de AWS. Está basado en una versión antigua de PostgreSQL, así que muchas funciones modernas de PostgreSQL no existen aquí. Es donde más sorpresas te llevas si vienes de un PostgreSQL reciente.
• ▹DuckDB — el motor analítico que has usado para practicar. Corre dentro de tu propio ordenador (o del navegador) sin instalar un servidor, y su dialecto es muy moderno y cercano al estándar. Cuando algo funciona en DuckDB y falla en Redshift, casi siempre es porque DuckDB es más nuevo, no porque estés haciendo algo mal.
• ▹SQL Server (Microsoft) — el motor relacional de Microsoft, muy presente en empresas grandes, banca y administración. No es un almacén analítico en la nube como los tres anteriores, pero te lo vas a encontrar, y es el que más se aparta del resto en el día a día: no tiene LIMIT sino TOP, concatena con + en vez de con ||, y rellena nulos con ISNULL. Si tu primer trabajo usa SQL Server, casi todo lo que verás en esta lección te va a hacer falta el primer día.

### Diferencia 1: limitar filas (LIMIT frente a TOP)

La más sencilla y la primera con la que tropieza casi todo el mundo. Quieres los tres productos que más facturan. En cinco de los seis motores escribes LIMIT 3 al final de la consulta, después del ORDER BY. Pero SQL Server, el motor de Microsoft que aparece muchísimo en empresas grandes y en la banca, no tiene LIMIT: usa TOP 3, y lo escribe en un sitio distinto, justo después del SELECT. Si copias una consulta con LIMIT y la pegas en SQL Server, te devuelve un error de sintaxis y punto.

1-- Los tres productos que más facturan.
2
3-- PostgreSQL, DuckDB, BigQuery, Snowflake, Redshift:
4SELECT nombre, ingresos
5FROM productos
6ORDER BY ingresos DESC
7LIMIT 3;
8
9-- SQL Server (Microsoft): no existe LIMIT.
10-- El TOP va justo después del SELECT. Funciona sin ORDER BY,
11-- pero entonces te da tres filas cualesquiera, no las tres mayores.
12-- Si quieres las tres mayores, el ORDER BY es obligatorio igual.
13SELECT TOP 3 nombre, ingresos
14FROM productos
15ORDER BY ingresos DESC;
16
17-- Truco de compatibilidad: la forma ANSI estándar (OFFSET ... FETCH) funciona en
18-- SQL Server, PostgreSQL, Oracle y otros. Es más larga, pero es la más portable:
19SELECT nombre, ingresos
20FROM productos
21ORDER BY ingresos DESC
22OFFSET 0 ROWS FETCH FIRST 3 ROWS ONLY;

### Diferencia 2: las fechas, el campo de minas

Si hay un sitio donde los dialectos se separan de verdad, es en las fechas. Extraer el mes de una fecha, redondear una fecha al primer día de su mes, sumar treinta días, calcular la diferencia entre dos fechas: todas esas operaciones tienen nombres y formas distintas según el motor. Es la zona donde más tiempo se pierde y donde más se copia mal de una respuesta de internet que estaba escrita para otro motor.

Hay cuatro funciones que conviene reconocer, porque son las que más aparecen y las que más cambian: EXTRACT para sacar una parte de la fecha (el año, el mes, el día); DATE_TRUNC para "truncar", es decir, redondear una fecha hacia abajo a la unidad que digas (a mes, a semana, a día); DATE_PART, que hace casi lo mismo que EXTRACT pero con otra sintaxis; y DATEADD para sumar o restar tiempo a una fecha. No todas existen en todos los motores, y las que existen a veces cambian el orden de los argumentos.

1-- OBJETIVO: agrupar pedidos por mes. Cada motor lo escribe a su manera.
2
3-- 1) Extraer el mes de una fecha
4-- PostgreSQL, DuckDB, Redshift, BigQuery:
5EXTRACT(MONTH FROM fecha)
6-- SQL Server: no tiene EXTRACT, usa DATEPART con otro orden:
7DATEPART(month, fecha)
8
9-- 2) Truncar la fecha al primer día del mes (para agrupar por mes de verdad)
10-- PostgreSQL, DuckDB, Snowflake, Redshift: la unidad va primero, entre comillas:
11DATE_TRUNC('month', fecha)
12-- BigQuery: la fecha va primero y la unidad SIN comillas. Argumentos al revés:
13DATE_TRUNC(fecha, MONTH)
14
15-- 3) Sumar un mes a una fecha
16-- PostgreSQL, DuckDB: aritmética de intervalos, muy legible:
17fecha + INTERVAL '1 month'
18-- SQL Server, Snowflake, Redshift: función DATEADD:
19DATEADD(month, 1, fecha)
20-- BigQuery: se llama DATE_ADD y usa la palabra INTERVAL:
21DATE_ADD(fecha, INTERVAL 1 MONTH)
22
23-- Nota: DATETRUNC en SQL Server solo existe en versiones recientes (2022+).
24-- En las antiguas hay que reconstruir la fecha a mano. Es de los casos
25-- donde no basta con saber el nombre de la función: hay que mirar la versión del motor.

### Diferencia 3: concatenar texto

Concatenar es pegar dos textos en uno: unir el nombre y el apellido en "Ana Ruiz", o montar una etiqueta como "Ana Ruiz (Sevilla)". Aquí hay tres escuelas. La mayoría de motores usan el operador doble barra vertical, escrito ||, que es lo que dicta el estándar ANSI. SQL Server no entiende esa doble barra y usa el signo más, +, como si sumara textos. Y casi todos, incluido SQL Server, entienden además la función CONCAT(), que es la opción más portable porque funciona en casi todas partes.

1-- Montar la etiqueta "Ana Ruiz (Sevilla)" a partir de tres columnas.
2
3-- PostgreSQL, DuckDB, Snowflake, Redshift, Oracle (el estándar ANSI):
4SELECT nombre || ' ' || apellido || ' (' || ciudad || ')' AS etiqueta
5FROM clientes;
6
7-- SQL Server: la doble barra no existe, se usa el signo más:
8SELECT nombre + ' ' + apellido + ' (' + ciudad + ')' AS etiqueta
9FROM clientes;
10
11-- CONCAT(): la opción más portable, funciona en casi todos (incluido SQL Server).
12-- Ojo: no mete separadores solo, hay que ponerlos a mano:
13SELECT CONCAT(nombre, ' ', apellido, ' (', ciudad, ')') AS etiqueta
14FROM clientes;

### Diferencia 4: los nulos

Un valor nulo (NULL) es "aquí no hay dato": no es cero, no es texto vacío, es la ausencia de valor. Muy a menudo quieres sustituir ese hueco por algo presentable, un cero en un importe o un "Sin asignar" en una región, para que el informe no salga con huecos. La función que hace eso tiene cuatro nombres distintos según el motor, y esta es de las diferencias que más se preguntan en entrevista porque parece de detalle y en realidad revela si has trabajado con más de un motor.

1-- Rellenar los huecos: region nula -> "Sin asignar", importe nulo -> 0.
2
3-- COALESCE: es el estándar ANSI y funciona EN TODOS. Acepta varios argumentos
4-- y devuelve el primero que no sea nulo. Si solo aprendes uno, aprende este:
5SELECT COALESCE(region, 'Sin asignar') AS region,
6       COALESCE(importe, 0)            AS importe
7FROM ventas;
8
9-- NVL: dos argumentos. Oracle y Redshift.
10SELECT NVL(region, 'Sin asignar') AS region FROM ventas;
11
12-- IFNULL: dos argumentos. MySQL, BigQuery, SQLite.
13SELECT IFNULL(region, 'Sin asignar') AS region FROM ventas;
14
15-- ISNULL: dos argumentos. SQL Server (ojo: en PostgreSQL ISNULL NO existe).
16SELECT ISNULL(region, 'Sin asignar') AS region FROM ventas;

### El método de los diez minutos

Lo importante no es saberte estas cuatro diferencias de memoria: es tener un método para resolver la número cinco, la que no hemos visto, cuando aparezca. Y aparecerá. El método es siempre el mismo y no lleva más de diez minutos. Lo repites hasta que se vuelve automático.

1. 01.Identifica qué motor tienes delante. Lo pone en la oferta, te lo dice el equipo, o lo ves en la cadena de conexión (redshift, bigquery, snowflake en la URL o en el tipo de conexión). Es el dato que decide todo lo demás.
2. 02.Ve a la documentación oficial de ESE motor, no a la primera respuesta de un buscador. Todas tienen su web de referencia y todas son buenas. Busca ahí la categoría "date functions", "string functions" o la que toque.
3. 03.Busca la función equivalente a lo que quieres hacer. Sabes qué necesitas ("truncar a mes", "rellenar nulos"): solo te falta el nombre y el orden de los argumentos en este motor concreto.
4. 04.Pruébala en una consulta mínima antes de meterla en la grande. Un SELECT de una línea con un valor de ejemplo te confirma que la función existe, que se llama así y que los argumentos van en ese orden. Diez segundos que te ahorran depurar una consulta de cuarenta líneas.

### En la prueba técnica: no memorices, traduce

Cuando te enfrentas a una prueba técnica de SQL, casi siempre te dicen antes qué motor vas a usar, o te dejan elegir. Nadie espera que te sepas de memoria la sintaxis de fechas de los cinco. Lo que sí evalúan es si sabes resolver el problema y si, ante una diferencia de dialecto, sabes salir del paso con calma en lugar de bloquearte. Si en mitad de una prueba no recuerdas si es DATE_TRUNC o DATEPART, decirlo en voz alta ("en el motor que uso a diario esto sería DATE_TRUNC, déjame confirmar la sintaxis exacta") suma puntos en vez de restarlos: demuestra que has trabajado con datos de verdad, donde estas cosas se consultan.

Resumiendo: SQL es un idioma con acentos. El vocabulario básico es el mismo en todas partes, y con él resuelves la mayor parte de tu trabajo. Las diferencias de dialecto se concentran en cuatro zonas conocidas (limitar filas, fechas, concatenar y nulos) y se resuelven con un método de diez minutos que se apoya en la documentación oficial. No inviertas tu energía en memorizar cinco motores: inviértela en dominar el tronco común y en saber traducir. Un analista que sabe traducir entre dialectos vale en cualquier empresa; uno que solo sabe un dialecto de memoria vale hasta que le cambian el motor.

Y con esto cierras algo más grande que una lección. Ya sabes leer el almacén que otros construyeron: entiendes su modelo en estrella, sabes de qué grano es cada tabla, dónde consultar sin multiplicar filas y en qué dialecto hablar con cada motor. El paso que falta es que todo eso no se quede en tus manos y tus consultas. Falta convertir esos datos en algo que cualquiera en la empresa pueda mirar sin escribir una sola línea de SQL: paneles que se leen de un vistazo, con las herramientas que existen para construirlos. De eso trata lo que viene ahora.