Bases De Datos · DacaCode

SQL: Transacciones, Índices y Constraints

Dacadev — Fri, 26 Jun 2026 00:00:00 -0500

Tabla de Contenido

En sistemas con múltiples usuarios escribiendo datos al mismo tiempo, la diferencia entre una aplicación confiable y una que corrompe información suele estar en cómo manejas transacciones en SQL, índices y constraints. En el artículo anterior analizamos Vistas (Views); ahora cerramos la serie con mecanismos de integridad y rendimiento.

Note

En este artículo vas a aprender cómo iniciar y cerrar transacciones con COMMIT y ROLLBACK, cuándo usar savepoints, cómo funcionan los índices B-tree, bitmap y full-text, y cómo las constraints mantienen reglas de integridad dentro del esquema.

Qué es una transacción en SQL

Una transacción agrupa una o varias sentencias SQL que deben ejecutarse como una unidad lógica. El objetivo es que los cambios se apliquen completos o no se apliquen en absoluto.

Consideremos una transferencia bancaria. Restar dinero de una cuenta y sumarlo a otra no son acciones independientes desde el punto de vista del negocio. Si una actualización se ejecuta y la otra falla, el sistema queda en un estado inconsistente.

START TRANSACTION;

 /* retirar dinero de la primera cuenta, validando saldo suficiente */
UPDATE account SET avail_balance = avail_balance - 500
WHERE account_id = 9988
 AND avail_balance > 500;

IF <exactly one row was updated by the previous statement> THEN
 /* depositar dinero en la segunda cuenta */
 UPDATE account SET avail_balance = avail_balance + 500
 WHERE account_id = 9989;

 IF <exactly one row was updated by the previous statement> THEN
 /* todo funcionó, hacer los cambios permanentes */
 COMMIT;
 ELSE
 /* algo falló, deshacer todos los cambios de esta transacción */
 ROLLBACK;
 END IF;
ELSE
 /* saldo insuficiente o error durante la actualización */
 ROLLBACK;
END IF;

En este flujo, COMMIT confirma los cambios y ROLLBACK revierte todo lo ejecutado desde el inicio de la transacción. La base de datos actúa como una frontera de consistencia.

Candados y concurrencia

Cuando varias sesiones intentan leer o escribir los mismos datos, el motor puede usar candados (locks) sobre filas, páginas o tablas. Los locks evitan que una transacción lea datos en transición o sobrescriba cambios que todavía no han sido confirmados.

Iniciar una transacción

Los servidores de base de datos suelen manejar la creación de transacciones de una de estas dos formas:

Siempre existe una transacción activa asociada a la sesión. Cuando la transacción actual termina, el servidor inicia automáticamente una nueva.
Cada sentencia SQL se confirma automáticamente, a menos que inicies una transacción explícita.

En MySQL, una transacción explícita puede comenzar con:

start transaction

Tip

Puedes configurar el comportamiento de autocommit según el motor y el cliente que uses.

Terminar una transacción

Una vez iniciada una transacción, necesitas terminarla explícitamente para que los cambios sean permanentes. COMMIT marca los cambios como definitivos y libera recursos usados durante la transacción,.

Si decides deshacer lo ejecutado desde el inicio de la transacción, usas ROLLBACK. El servidor devuelve los datos al estado previo de la transacción.

Además de COMMIT y ROLLBACK, una transacción puede terminar por otros eventos:

El servidor se apaga; al reiniciar, la transacción pendiente se revierte automáticamente.
Ejecutas una sentencia de esquema como ALTER TABLE; en varios motores esto puede confirmar la transacción actual e iniciar otra.
Ejecutas otro START TRANSACTION; algunos motores confirman la transacción anterior antes de abrir la nueva.
El servidor detecta un deadlock, elige una transacción como víctima y la revierte para desbloquear el sistema.

Warning

Las sentencias DDL no siempre participan en transacciones igual que las sentencias DML. Antes de mezclar ALTER TABLE, CREATE INDEX o cambios de esquema con operaciones de datos, revisa el comportamiento específico de tu motor.

Savepoints dentro de una transacción

Los savepoints permiten definir puntos intermedios de rollback dentro de una misma transacción. En lugar de revertir todo, puedes regresar a un punto específico y continuar trabajando.

Índices y constraints

Una consulta sin apoyo puede obligar al servidor a escanear fila por fila. En tablas con millones de registros y decenas de columnas, esto se convierte en un cuello de botella.

Los índices son estructuras auxiliares que permiten encontrar filas con menos trabajo. Aceleran búsquedas, filtros, joins y ordenamientos.

Creación de índices

Para crear un índice en MySQL podemos usar ALTER TABLE. Supongamos que el sistema consulta clientes frecuentemente por correo electrónico:

mysql> ALTER TABLE customer
 -> ADD INDEX idx_email (email);
Query OK, 0 rows affected (1.87 sec)
Records: 0 Duplicates: 0 Warnings: 0

Después de crear el índice, el optimizador decide si conviene usarlo. El motor evalúa estadísticas, cardinalidad y costo estimado.

Podemos inspeccionar los índices existentes con SHOW INDEX:

mysql> SHOW INDEX FROM customer \G;
*************************** 1. row ***************************
 Table: customer
 Non_unique: 1
 Key_name: idx_email
 Seq_in_index: 1
 Column_name: email
 Collation: A
 Cardinality: 599
 Sub_part: NULL
 Packed: NULL
 Null: YES
 Index_type: BTREE
...
5 rows in set (0.06 sec)

Y también podemos eliminarlos cuando dejan de aportar valor:

mysql> ALTER TABLE customer
 -> DROP INDEX idx_email;
Query OK, 0 rows affected (0.50 sec)
Records: 0 Duplicates: 0 Warnings: 0

Info

Cada índice ocupa espacio y debe actualizarse cuando cambian las filas afectadas. Un índice acelera lecturas específicas, pero también puede encarecer escrituras como INSERT, UPDATE y DELETE.

Índices únicos

Un índice único cumple dos funciones: acelera búsquedas y evita valores duplicados en las columnas indexadas. Cada vez que insertas una fila o modificas la columna, el servidor valida si el valor ya existe.

mysql> ALTER TABLE customer
 -> ADD UNIQUE idx_email (email);
Query OK, 0 rows affected (0.64 sec)
Records: 0 Duplicates: 0 Warnings: 0

Si intentas insertar un cliente con un email ya registrado, el motor rechaza la operación:

mysql> INSERT INTO customer
 -> (store_id, first_name, last_name, email, address_id, active)
 -> VALUES
 -> (1,'ALAN','KAHN', 'ALAN.KAHN@sakilacustomer.org', 394, 1);
ERROR 1062 (23000): Duplicate entry 'ALAN.KAHN@sakilacustomer.org' 
 for key 'idx_email'

Índices multicolumna

También puedes crear índices que cubren varias columnas. Si buscas clientes por apellido y nombre, un índice compuesto puede ser más útil que dos índices separados.

mysql> ALTER TABLE customer
 -> ADD INDEX idx_full_name (last_name, first_name);
Query OK, 0 rows affected (0.35 sec)
Records: 0 Duplicates: 0 Warnings: 0

El orden importa. Un índice (last_name, first_name) ayuda a consultas que filtran por last_name o por last_name junto con first_name. No ayuda igual a una consulta que filtra solo por first_name.

Tipos de índices

Índices B-tree

Los índices B-tree organizan los valores como árboles balanceados. Los branch nodes sirven para navegar por rangos, mientras que los leaf nodes almacenan los valores reales del índice.

Branch nodes dirigen la búsqueda hacia el rango correcto; leaf nodes contienen las entradas finales asociadas a los valores indexados.

flowchart TD
 root["Nodo raíz
A - M | N - Z"]
 b1["A-C | D-F | G-I | J-M"]
 b2["N-P | Q-S | T-V | W-Z"]
 root --> b1
 root --> b2
 b1 --> l1["Barker
Blake"]
 b1 --> l2["Fleming
Fowler"]
 b1 --> l3["Gooding
Grossman
Hawthorne"]
 b1 --> l4["Jameson
Markham
Mason"]
 b2 --> l5["Parker
Portman"]
 b2 --> l6["Roberts
Smith"]
 b2 --> l7["Tucker
Tulman
Tyler"]
 b2 --> l8["Ziegler"]

Este tipo de índice funciona muy bien para columnas con muchos valores distintos, como customer.last_name, fechas, identificadores externos o campos usados en rangos.

Índices bitmap

Los bitmap indexes están diseñados para columnas de baja cardinalidad, es decir, columnas con pocos valores posibles repetidos en muchas filas. Un ejemplo clásico es customer.active, donde puede haber solo 1 para activo y 0 para inactivo.

En lugar de mantener un árbol grande, el motor mantiene bitmaps por valor. Para consultar clientes inactivos, puede recorrer el bitmap del valor 0 y localizar las filas correspondientes.

Esta estrategia es compacta para baja cardinalidad, pero se degrada cuando la columna tiene demasiados valores distintos.

Índices de texto

Cuando almacenas documentos o contenido largo, buscar palabras con un escaneo completo es costoso.

MySQL y SQL Server ofrecen índices full-text; Oracle incluye herramientas bajo Oracle Text. Estos mecanismos están especializados para documentos y búsquedas textuales.

Cómo se usan los índices

Los índices permiten acceder rápidamente a datos, pero el motor decide si usarlos según el plan de ejecución. Un índice creado no garantiza automáticamente una consulta más rápida.

Observemos tres criterios prácticos:

Crea índices alrededor de consultas frecuentes, no alrededor de columnas al azar.
Evita indexar columnas con baja selectividad usando B-tree si el motor ofrece una estrategia mejor.
Mide el impacto en escrituras, porque cada índice debe mantenerse actualizado.

Constraints: restricciones de integridad

Una constraint es una restricción aplicada a una o más columnas de una tabla. Vive dentro del esquema y protege los datos desde la base.

Los tipos principales son:

Primary key constraints: identifican la columna o combinación de columnas que garantizan unicidad dentro de una tabla.
Foreign key constraints: restringen una o más columnas para que contengan valores existentes en la primary key de otra tabla.
Unique constraints: evitan duplicados en una o más columnas; una primary key es un caso especial de unicidad.
Check constraints: restringen los valores permitidos para una columna según una condición.

Normalmente las constraints se crean junto con la tabla usando CREATE TABLE. Este ejemplo del esquema Sakila combina primary key, índices y foreign keys:

CREATE TABLE customer (
 customer_id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
 store_id TINYINT UNSIGNED NOT NULL,
 first_name VARCHAR(45) NOT NULL,
 last_name VARCHAR(45) NOT NULL,
 email VARCHAR(50) DEFAULT NULL,
 address_id SMALLINT UNSIGNED NOT NULL,
 active BOOLEAN NOT NULL DEFAULT TRUE,
 create_date DATETIME NOT NULL,
 last_update TIMESTAMP DEFAULT CURRENT_TIMESTAMP 
 ON UPDATE CURRENT_TIMESTAMP,
 PRIMARY KEY (customer_id),
 KEY idx_fk_store_id (store_id),
 KEY idx_fk_address_id (address_id),
 KEY idx_last_name (last_name),
 CONSTRAINT fk_customer_address FOREIGN KEY (address_id) 
 REFERENCES address (address_id) ON DELETE RESTRICT ON UPDATE CASCADE,
 CONSTRAINT fk_customer_store FOREIGN KEY (store_id) 
 REFERENCES store (store_id) ON DELETE RESTRICT ON UPDATE CASCADE
)ENGINE=InnoDB DEFAULT CHARSET=utf8;

También puedes agregar constraints después con ALTER TABLE:

ALTER TABLE customer
ADD CONSTRAINT fk_customer_address FOREIGN KEY (address_id)
REFERENCES address (address_id) ON DELETE RESTRICT ON UPDATE CASCADE;

ALTER TABLE customer
ADD CONSTRAINT fk_customer_store FOREIGN KEY (store_id)
REFERENCES store (store_id) ON DELETE RESTRICT ON UPDATE CASCADE;

La cláusula ON DELETE RESTRICT protege contra registros huérfanos cuando se intenta eliminar una fila padre.

Para foreign keys, las acciones comunes ante borrados y actualizaciones son:

ON DELETE RESTRICT: impide borrar la fila padre si existen filas hijas relacionadas.
ON DELETE CASCADE: borra automáticamente las filas hijas cuando se borra la fila padre.
ON DELETE SET NULL: asigna NULL en la foreign key de las filas hijas cuando se borra la fila padre.
ON UPDATE RESTRICT: impide actualizar la clave padre si hay filas hijas relacionadas.
ON UPDATE CASCADE: propaga el cambio de clave hacia las filas hijas.
ON UPDATE SET NULL: asigna NULL en la foreign key de las filas hijas cuando cambia la clave padre.

Warning

CASCADE es potente, pero debe modelarse con cuidado. Una eliminación pequeña puede disparar borrados en varias tablas.

Conclusión de la serie SQL

Las transacciones, índices y constraints completan la base práctica para trabajar con SQL de forma profesional. Protegen operaciones compuestas, reducen el costo de acceso a datos y llevan reglas críticas al esquema.

Con este artículo cerramos la serie de SQL. Para repasar desde el inicio, vuelve a: Fundamentos SQL: SELECT, FROM y WHERE. Desde ahí puedes recorrer consultas, filtros, joins, agrupaciones, subconsultas, vistas y estos mecanismos de integridad y rendimiento.

SQL: Vistas (Views) para Abstraer y Asegurar tus Datos

Dacadev — Tue, 23 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una base de datos crece, las consultas empiezan a acumular lógica de negocio, joins repetidos, filtros de seguridad y columnas calculadas. En ese punto, las vistas en SQL se vuelven una herramienta clave: con CREATE VIEW podemos encapsular una consulta y exponerla como si fuera una tabla lógica. En el artículo anterior vimos subqueries y subconsultas; ahora vamos a usar ese mismo nivel de composición para abstraer, asegurar y simplificar el acceso a datos.

Note

En este artículo analizaremos qué es una vista, cómo crearla con CREATE VIEW, por qué ayuda con seguridad, agregación, complejidad y datos distribuidos, y qué condiciones debe cumplir una vista para ser actualizable.

Qué es una vista

Una vista no es una tabla física. En términos prácticos, es una consulta guardada en la base de datos que puedes consultar con SELECT como si fuera una tabla. La vista no almacena los registros por sí misma; almacena la definición del query que se ejecutará cuando accedas a ella.

Esto reduce repetición y mejora la legibilidad. Si una consulta se usa todos los días, o si quieres exponer solo ciertas columnas a un equipo o aplicación, una vista ofrece una interfaz estable sobre las tablas base.

Consideremos una vista sobre la tabla customer:

CREATE VIEW customer_vw
 (customer_id,
 first_name,
 last_name,
 email 
 )
AS
SELECT 
 customer_id,
 first_name,
 last_name,
 concat(substr(email,1,2), '*****', substr(email, -4)) email
FROM customer;

En este ejemplo, la vista customer_vw expone customer_id, first_name, last_name y email. Observemos un detalle importante: el email no se entrega completo, sino enmascarado mediante concat() y substr().

Para usar la vista, la consultamos como cualquier otra relación:

mysql> SELECT first_name, last_name, email
 -> FROM customer_vw;
+-------------+--------------+-------------+
| first_name | last_name | email |
+-------------+--------------+-------------+
| MARY | SMITH | MA*****.org |
| PATRICIA | JOHNSON | PA*****.org |
| LINDA | WILLIAMS | LI*****.org |
| BARBARA | JONES | BA*****.org |
| ELIZABETH | BROWN | EL*****.org |
...
| ENRIQUE | FORSYTHE | EN*****.org |
| FREDDIE | DUGGAN | FR*****.org |
| WADE | DELVALLE | WA*****.org |
| AUSTIN | CINTRON | AU*****.org |
+-------------+--------------+-------------+
599 rows in set (0.00 sec)

La consulta queda más expresiva: en lugar de repetir el cálculo del email en cada reporte, centralizamos esa lógica en una vista.

Si necesitas inspeccionar la estructura de una vista, puedes usar DESCRIBE o su forma corta DESC:

mysql> describe customer_vw;
+-------------+----------------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------+----------------------+------+-----+---------+-------+
| customer_id | smallint(5) unsigned | NO | | 0 | |
| first_name | varchar(45) | NO | | NULL | |
| last_name | varchar(45) | NO | | NULL | |
| email | varchar(11) | YES | | NULL | |
+-------------+----------------------+------+-----+---------+-------+
4 rows in set (0.00 sec)

Tip

Puedes usar en vistas gran parte de lo que ya conoces de SQL: WHERE, ORDER BY, GROUP BY, funciones, expresiones calculadas e incluso JOIN. La vista encapsula la consulta; no elimina la necesidad de diseñarla correctamente.

Por qué usar vistas

Las vistas son útiles cuando necesitas definir una capa de acceso estable entre las tablas reales y los consumidores de datos. Esa capa puede servir para seguridad, reporting, simplificación de consultas o unificación de datos.

Seguridad de los datos

Cuando los usuarios consultan directamente las tablas base, pueden quedar expuestas columnas sensibles que no deberían estar disponibles para todos los perfiles. Una vista permite publicar solo las columnas necesarias y, si hace falta, transformar datos antes de mostrarlos.

El ejemplo de customer_vw aplica este patrón: el email se expone enmascarado. En una aplicación interna, podrías conceder permisos sobre la vista y evitar permisos directos sobre customer. Así reduces superficie de exposición sin duplicar datos.

Este enfoque también estabiliza contratos. Si la tabla base contiene más columnas en el futuro, los consumidores de la vista no las reciben automáticamente.

Agregar datos

Las vistas también funcionan bien para reportes o consultas agregadas. Si un equipo necesita revisar ventas por categoría de película, no tiene que escribir todos los JOIN cada vez.

CREATE VIEW sales_by_film_category
AS
SELECT
 c.name AS category,
 SUM(p.amount) AS total_sales
FROM payment AS p
 INNER JOIN rental AS r ON p.rental_id = r.rental_id
 INNER JOIN inventory AS i ON r.inventory_id = i.inventory_id
 INNER JOIN film AS f ON i.film_id = f.film_id
 INNER JOIN film_category AS fc ON f.film_id = fc.film_id
 INNER JOIN category AS c ON fc.category_id = c.category_id
GROUP BY c.name
ORDER BY total_sales DESC;

Esta vista encapsula una agregación de pagos por categoría. El consumidor puede ejecutar SELECT * FROM sales_by_film_category; y enfocarse en el resultado, no en la mecánica de las relaciones.

Info

Una vista con agregaciones no materializa necesariamente el resultado. En muchos motores, la consulta se evalúa al leer la vista. Si el reporte es costoso y se consulta con alta frecuencia, analiza índices, planes de ejecución o alternativas como vistas materializadas cuando tu motor las soporte.

Esconder complejidad

Otra ventaja importante es ocultar consultas complejas detrás de un nombre claro. Analicemos una vista que resume estadísticas de películas usando subconsultas:

CREATE VIEW film_stats
AS
SELECT f.film_id, f.title, f.description, f.rating,
 (SELECT c.name
 FROM category c
 INNER JOIN film_category fc
 ON c.category_id = fc.category_id
 WHERE fc.film_id = f.film_id) category_name,
 (SELECT count(*)
 FROM film_actor fa
 WHERE fa.film_id = f.film_id
 ) num_actors,
 (SELECT count(*)
 FROM inventory i
 WHERE i.film_id = f.film_id
 ) inventory_cnt,
 (SELECT count(*)
 FROM inventory i
 INNER JOIN rental r
 ON i.inventory_id = r.inventory_id
 WHERE i.film_id = f.film_id
 ) num_rentals
FROM film f;

Esta consulta mezcla columnas directas, subqueries correlacionadas y conteos derivados. Usar film_stats como interfaz simplifica el consumo y reduce errores de copia al reutilizar la lógica.

También mejora la comunicación técnica. Un nombre como film_stats expresa intención de negocio mejor que una consulta extensa pegada en múltiples servicios, dashboards o scripts.

Datos distribuidos o particionados

Las vistas pueden ayudar a unificar datos que viven en diferentes tablas. Si una tabla está particionada por año, por región o por tipo de entidad, una vista puede presentar una estructura más simple para quien consulta.

El objetivo no es ocultar decisiones arquitectónicas críticas, sino evitar que cada consumidor tenga que conocer todos los detalles físicos del modelo. Una vista puede funcionar como una API interna de lectura dentro de la base de datos.

Vistas actualizables

Hasta ahora hemos usado vistas para leer datos. Sin embargo, algunos motores permiten ejecutar UPDATE, INSERT o DELETE a través de una vista, siempre que la base de datos pueda mapear la operación de forma inequívoca hacia las tablas base.

No todas las vistas son actualizables. Mientras más transformación tenga una vista, más difícil será determinar qué fila y qué columna real debe modificarse.

Para que una vista sea actualizable, considera estas restricciones típicas:

No se usan funciones de agregación como max(), min(), avg(), sum() o similares.
La vista no utiliza cláusulas GROUP BY ni HAVING.
No existen subconsultas en el SELECT ni en el FROM; y las subconsultas en el WHERE, si existen, no hacen referencia a tablas del FROM.
La vista no utiliza UNION, UNION ALL ni DISTINCT.
La cláusula FROM incluye al menos una tabla o una vista actualizable.
Si hay más de una tabla o vista en el FROM, se usan únicamente INNER JOIN.

Warning

Las reglas exactas dependen del motor de base de datos. MySQL, PostgreSQL, SQL Server y Oracle tienen diferencias en sintaxis, permisos y casos soportados. Antes de depender de escrituras sobre vistas en producción, valida el comportamiento en tu motor específico.

Actualizando vistas simples

Supongamos nuevamente la vista customer_vw:

CREATE VIEW customer_vw
 (customer_id,
 first_name,
 last_name,
 email
 )
AS
SELECT
 customer_id,
 first_name,
 last_name,
 concat(substr(email,1,2), '*****', substr(email, -4)) email
FROM customer;

Podemos actualizar una columna directa de la tabla base, como last_name, usando la vista:

mysql> UPDATE customer_vw
 -> SET last_name = 'SMITH-ALLEN'
 -> WHERE customer_id = 1;
Query OK, 1 row affected (0.11 sec)
Rows matched: 1 Changed: 1 Warnings: 0

La operación funciona porque last_name corresponde directamente a una columna actualizable de customer. La vista actúa como una capa de acceso, pero el motor sabe qué valor modificar.

En cambio, si intentamos actualizar email, la operación falla:

mysql> UPDATE customer_vw
 -> SET email = 'MARY.SMITH-ALLEN@sakilacustomer.org'
 -> WHERE customer_id = 1;
ERROR 1348 (HY000): Column 'email' is not updatable

La razón es que email en la vista no es la columna original; es una expresión calculada con concat() y substr(). El motor no puede inferir cómo convertir el valor nuevo en una actualización válida de la columna base.

También debes tener cuidado con INSERT. Insertar a través de una vista falla cuando la vista no expone todas las columnas NOT NULL de la tabla base, por lo que el INSERT no puede proporcionar valores para ellas. Si esas columnas no tienen DEFAULT, el motor no tiene forma segura de completar la fila.

Conclusión

Las vistas en SQL son una herramienta de diseño para crear interfaces de datos más limpias. Con CREATE VIEW puedes encapsular consultas repetidas, proteger columnas sensibles, construir reportes agregados y esconder complejidad sin duplicar información.

También es importante reconocer sus límites. Una vista no reemplaza un buen diseño de índices, no siempre mejora rendimiento y no siempre permite escritura. Cuando una vista incluye agregaciones, expresiones calculadas, DISTINCT, UNION o subconsultas complejas, normalmente debes tratarla como una interfaz de lectura.

Como siguiente paso de la serie, analizaremos cómo proteger la consistencia y el rendimiento de operaciones más críticas con transacciones, índices y constraints.

SQL: Subqueries y Tipos de JOIN Avanzados

Dacadev — Sat, 20 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando tus consultas SQL empiezan a mezclar filtros, agregaciones y relaciones entre tablas, los JOIN básicos dejan de ser suficientes para expresar ciertas reglas de negocio con claridad. Las subqueries o subconsultas en SQL permiten encapsular una consulta dentro de otra, reutilizar resultados intermedios y construir filtros más precisos sin mover lógica innecesaria a la aplicación. En el artículo anterior vimos consultas a múltiples tablas con JOINs; ahora vamos a extender esa base con subconsultas, EXISTS y tipos de JOIN más avanzados.

Note

En este artículo aprenderás a usar subqueries escalares, subconsultas de múltiples filas, subqueries correlacionadas, el operador EXISTS, LEFT OUTER JOIN, CROSS JOIN y NATURAL JOIN.

Qué es una subquery en SQL

Una subquery es una consulta contenida dentro de otra sentencia SQL. A la sentencia externa la llamaremos consulta contenedora o consulta principal. La subquery siempre va entre paréntesis y, en muchos motores, se evalúa antes de que la consulta principal termine de resolver su filtro o su conjunto de datos.

Como cualquier consulta, una subquery puede retornar diferentes formas de resultado:

Una sola fila con una sola columna.
Múltiples filas con una sola columna.
Múltiples filas con múltiples columnas.

Analicemos un primer ejemplo. Queremos obtener el cliente con el customer_id más alto:

mysql> SELECT customer_id, first_name, last_name
 -> FROM customer
 -> WHERE customer_id = (SELECT MAX(customer_id) FROM customer);
+-------------+------------+-----------+
| customer_id | first_name | last_name |
+-------------+------------+-----------+
| 599 | AUSTIN | CINTRON |
+-------------+------------+-----------+
1 row in set (0.27 sec)

La subquery (SELECT MAX(customer_id) FROM customer) retorna un único valor. Por eso podemos compararla con = en el WHERE de la consulta principal.

Info

Cuando una subquery retorna una fila y una sola columna, se comporta como una subquery escalar. Puedes usarla con operadores como =, <>, !=, >, >=, < y <=.

Tipos de subqueries

No todas las subconsultas tienen el mismo comportamiento. La diferencia más importante está en si la subquery depende o no de la consulta principal.

Subqueries no correlacionadas

Las subqueries no correlacionadas no dependen directamente de la consulta contenedora. Puedes ejecutarlas por separado, inspeccionar su resultado y luego entender cómo ese resultado alimenta el WHERE, HAVING o incluso el FROM de la consulta principal.

El ejemplo anterior es una subquery no correlacionada. Observemos otro caso: obtener todas las ciudades cuyo país no sea India.

mysql> SELECT city_id, city
 -> FROM city
 -> WHERE country_id <> 
 -> (SELECT country_id FROM country WHERE country = 'India');
+---------+----------------------------+
| city_id | city |
+---------+----------------------------+
| 1 | A Corua (La Corua) |
| 2 | Abha |
| 3 | Abu Dhabi |
| 4 | Acua |
...
| 599 | Zhoushan |
| 600 | Ziguinchor |
+---------+----------------------------+
540 rows in set (0.02 sec)

Aquí la subquery retorna el country_id asociado a India. La consulta principal usa ese valor para excluir todas las ciudades que pertenezcan a ese país.

Warning

Si usas = con una subquery que retorna más de un valor, el motor no puede comparar un valor escalar contra un conjunto de filas. En ese caso necesitas operadores como IN, ANY, ALL o reestructurar la consulta.

Subqueries de múltiples filas y una columna

Cuando una subquery retorna varias filas pero una sola columna, IN suele ser el operador adecuado. Este operador compara el valor del lado izquierdo contra el conjunto de valores retornado por la subquery.

Consideremos una consulta para obtener ciudades de Canadá o México:

mysql> SELECT city_id, city
 -> FROM city
 -> WHERE country_id IN
 -> (SELECT country_id
 -> FROM country
 -> WHERE country IN ('Canada','Mexico'));
+---------+----------------------------+
| city_id | city |
+---------+----------------------------+
| 179 | Gatineau |
| 196 | Halifax |
| 300 | Lethbridge |
| 313 | London |
...
| 556 | Uruapan |
| 595 | Zapopan |
+---------+----------------------------+
37 rows in set (0.00 sec)

La subquery retorna los country_id de ambos países. Luego IN filtra las ciudades cuyo country_id esté dentro de ese conjunto.

Subqueries multicolumna

Las subqueries multicolumna retornan más de una columna y son útiles cuando necesitas comparar combinaciones de valores o enriquecer la lógica de selección. En SQL también es común resolver este tipo de necesidad con varias subqueries coordinadas, especialmente cuando cada filtro opera sobre una dimensión diferente.

Observemos este caso: queremos encontrar pares actor_id y film_id donde el actor tenga apellido MONROE y la película tenga clasificación PG.

mysql> SELECT fa.actor_id, fa.film_id
 -> FROM film_actor fa
 -> WHERE fa.actor_id IN
 -> (SELECT actor_id FROM actor WHERE last_name = 'MONROE')
 -> AND fa.film_id IN
 -> (SELECT film_id FROM film WHERE rating = 'PG');
+----------+---------+
| actor_id | film_id |
+----------+---------+
| 120 | 63 |
| 120 | 144 |
| 120 | 414 |
...
| 178 | 983 |
+----------+---------+
11 rows in set (0.00 sec)

Esta consulta combina dos filtros independientes: uno sobre actores y otro sobre películas. El resultado final sale de la tabla intermedia film_actor, que representa la relación muchos-a-muchos.

Subqueries correlacionadas

Hasta ahora, las subqueries han sido independientes. Una subquery correlacionada, en cambio, depende de la consulta principal porque referencia una o más columnas de la fila que se está evaluando afuera.

Esto cambia el modelo mental: la subquery no se ejecuta una sola vez para producir un conjunto estático, sino que puede evaluarse por cada fila candidata de la consulta externa. Por eso conviene revisar su costo, especialmente en tablas grandes.

Analicemos una consulta que obtiene clientes con exactamente 20 rentas:

mysql> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE 20 =
 -> (SELECT count(*) FROM rental r
 -> WHERE r.customer_id = c.customer_id);
+------------+-------------+
| first_name | last_name |
+------------+-------------+
| LAUREN | HUDSON |
| JEANETTE | GREENE |
| TARA | RYAN |
| WILMA | RICHARDS |
...
| ALFREDO | MCADAMS |
+------------+-------------+
15 rows in set (0.01 sec)

La parte clave es r.customer_id = c.customer_id. La subquery necesita el customer_id de la fila actual de customer, por eso está correlacionada.

El operador EXISTS

El operador EXISTS valida si la subquery retorna al menos una fila. No importa qué columnas seleccione la subquery; lo relevante es la existencia de registros que cumplan la condición.

Por convención, muchas consultas usan SELECT 1 dentro de EXISTS para indicar que el valor retornado no es importante:

mysql> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE EXISTS
 -> (SELECT 1 FROM rental r
 -> WHERE r.customer_id = c.customer_id
 -> AND date(r.rental_date) < '2005-05-25');
+------------+-------------+
| first_name | last_name |
+------------+-------------+
| CHARLOTTE | HUNTER |
| DELORES | HANSEN |
| MINNIE | ROMERO |
...
| NELSON | CHRISTENSON |
+------------+-------------+
8 rows in set (0.03 sec)

EXISTS es especialmente expresivo cuando la pregunta de negocio es binaria: “incluye esta fila si existe al menos una relación que cumple la condición”.

Tip

Usa EXISTS cuando quieras comprobar existencia y IN cuando quieras comparar contra un conjunto concreto de valores. Ambos pueden ser optimizados por el motor, pero expresan intenciones distintas.

JOINs avanzados: revisitando las uniones

Hasta este punto de la serie hemos trabajado principalmente con INNER JOIN. Ese tipo de unión retorna únicamente las filas que cumplen la condición en ambas tablas. Sin embargo, SQL ofrece variantes útiles para preservar filas sin coincidencias, generar combinaciones cartesianas o delegar la condición de unión al motor.

Outer joins

Los outer joins retornan las filas que cumplen la condición de unión y, además, conservan filas de una tabla aunque no tengan coincidencias del otro lado. En un LEFT OUTER JOIN, se preservan todas las filas de la tabla de la izquierda.

Observemos un conteo de copias por película:

mysql> SELECT f.film_id, f.title, count(i.inventory_id) num_copies
 -> FROM film f
 -> LEFT OUTER JOIN inventory i
 -> ON f.film_id = i.film_id
 -> GROUP BY f.film_id, f.title;
+---------+-----------------------------+------------+
| film_id | title | num_copies |
+---------+-----------------------------+------------+
| 1 | ACADEMY DINOSAUR | 8 |
| 2 | ACE GOLDFINGER | 3 |
| 3 | ADAPTATION HOLES | 4 |
| 4 | AFFAIR PREJUDICE | 7 |
...
| 14 | ALICE FANTASIA | 0 |
...
| 999 | ZOOLANDER FICTION | 5 |
| 1000 | ZORRO ARK | 8 |
+---------+-----------------------------+------------+
1000 rows in set (0.01 sec)

ALICE FANTASIA aparece con 0 copias porque no tiene registros asociados en inventory. Aun así, el LEFT OUTER JOIN conserva la película porque film está a la izquierda.

Veamos la misma situación sin agregación:

mysql> SELECT f.film_id, f.title, i.inventory_id
 -> FROM film f
 -> LEFT OUTER JOIN inventory i
 -> ON f.film_id = i.film_id
 -> WHERE f.film_id BETWEEN 13 AND 15;
+---------+----------------+--------------+
| film_id | title | inventory_id |
+---------+----------------+--------------+
| 13 | ALI FOREVER | 67 |
| 13 | ALI FOREVER | 68 |
| 13 | ALI FOREVER | 69 |
| 13 | ALI FOREVER | 70 |
| 14 | ALICE FANTASIA | NULL |
| 15 | ALIEN CENTER | 71 |
| 15 | ALIEN CENTER | 72 |
| 15 | ALIEN CENTER | 73 |
| 15 | ALIEN CENTER | 74 |
| 15 | ALIEN CENTER | 75 |
| 15 | ALIEN CENTER | 76 |
+---------+----------------+--------------+
11 rows in set (0.00 sec)

El NULL en inventory_id indica que no existe fila relacionada en la tabla derecha.

Outer joins de tres tablas

Puedes encadenar OUTER JOIN para preservar filas a través de varias relaciones. En este tipo de consulta, el orden importa porque define qué conjunto de filas se conserva en cada paso.

mysql> SELECT f.film_id, f.title, i.inventory_id, r.rental_date
 -> FROM film f
 -> LEFT OUTER JOIN inventory i
 -> ON f.film_id = i.film_id
 -> LEFT OUTER JOIN rental r
 -> ON i.inventory_id = r.inventory_id
 -> WHERE f.film_id BETWEEN 13 AND 15;
+---------+----------------+--------------+---------------------+
| film_id | title | inventory_id | rental_date |
+---------+----------------+--------------+---------------------+
| 13 | ALI FOREVER | 67 | 2005-07-31 18:11:17 |
| 13 | ALI FOREVER | 67 | 2005-08-22 21:59:29 |
| 13 | ALI FOREVER | 68 | 2005-07-28 15:26:20 |
...
| 14 | ALICE FANTASIA | NULL | NULL |
| 15 | ALIEN CENTER | 71 | 2005-05-28 02:06:37 |
...
| 15 | ALIEN CENTER | 76 | 2005-08-17 07:26:47 |
+---------+----------------+--------------+---------------------+
32 rows in set (0.01 sec)

Tip

Aunque existe RIGHT OUTER JOIN, en muchos equipos se prefiere estandarizar en LEFT OUTER JOIN. Mantiene la lectura de izquierda a derecha y reduce cambios mentales al revisar consultas complejas.

Cross joins

Un CROSS JOIN produce un producto cartesiano: combina cada fila de la primera tabla con cada fila de la segunda. Es útil para generar matrices de combinaciones, calendarios, catálogos base o escenarios de prueba, pero puede crecer muy rápido.

mysql> SELECT c.name category_name, l.name language_name
 -> FROM category c
 -> CROSS JOIN language l;
+---------------+---------------+
| category_name | language_name |
+---------------+---------------+
| Action | English |
| Action | Italian |
| Action | Japanese |
...
| Travel | English |
| Travel | German |
+---------------+---------------+
96 rows in set (0.00 sec)

Si category tiene 16 filas y language tiene 6, el resultado tendrá 96 filas. Esa multiplicación es exactamente el comportamiento esperado.

Natural joins

NATURAL JOIN deja que el motor determine las columnas de unión usando columnas con el mismo nombre en ambas tablas. Es importante conocerlo, pero no suele ser buena práctica en consultas de producción porque oculta la condición real del JOIN.

El siguiente ejemplo no retorna filas:

mysql> SELECT c.first_name, c.last_name, date(r.rental_date)
 -> FROM customer c
 -> NATURAL JOIN rental r;
Empty set (0.04 sec)

El problema es que customer y rental pueden compartir más columnas de las que realmente queremos usar como condición natural. Al proyectar únicamente las columnas necesarias desde customer, el NATURAL JOIN puede comportarse como esperamos:

mysql> SELECT cust.first_name, cust.last_name, date(r.rental_date)
 -> FROM
 -> (SELECT customer_id, first_name, last_name
 -> FROM customer
 -> ) cust
 -> NATURAL JOIN rental r;
+------------+-----------+---------------------+
| first_name | last_name | date(r.rental_date) |
+------------+-----------+---------------------+
| MARY | SMITH | 2005-05-25 |
| MARY | SMITH | 2005-05-28 |
| MARY | SMITH | 2005-06-15 |
...
| AUSTIN | CINTRON | 2005-08-23 |
+------------+-----------+---------------------+
16044 rows in set (0.03 sec)

Warning

Prefiere JOIN ... ON ... cuando la consulta debe ser mantenible. La condición explícita documenta la intención y evita cambios inesperados si el esquema gana nuevas columnas con nombres compartidos.

Conclusión

Las subqueries en SQL te permiten expresar reglas de negocio que dependen de resultados intermedios sin salir del motor de base de datos. Las subconsultas no correlacionadas son ideales para filtros basados en conjuntos estáticos; las correlacionadas son útiles cuando cada fila externa necesita una evaluación específica; y EXISTS comunica con claridad validaciones de existencia.

En el lado de los JOIN, LEFT OUTER JOIN conserva filas sin coincidencias, CROSS JOIN genera combinaciones cartesianas y NATURAL JOIN delega la condición al motor, aunque conviene usarlo con cuidado. La clave es elegir la herramienta que haga más explícita la intención de la consulta.

En el siguiente artículo de la serie vamos a trabajar con Vistas (Views), una forma práctica de encapsular consultas y exponer modelos de lectura reutilizables dentro de la base de datos.

SQL: Consultas a Múltiples Tablas con JOINs

Dacadev — Wed, 17 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una aplicación modela procesos reales, una sola tabla rara vez contiene todo el contexto. Clientes requieren direcciones, películas requieren actores y reportes operativos combinan varias entidades. Por eso, dominar consultas a múltiples tablas y entender cada JOIN en SQL es clave para escribir consultas correctas, expresivas y mantenibles.

En el artículo anterior trabajamos agrupamiento y funciones agregadas. Ahora conectaremos ese análisis con relaciones entre tablas.

Note

Aprenderás a usar INNER JOIN, unir tres o más tablas, reutilizar tablas con alias, aplicar SELF JOIN y combinar resultados con UNION, INTERSECT y EXCEPT.

Producto cartesiano

El producto cartesiano aparece cuando haces un JOIN entre dos tablas sin definir la condición que relaciona sus filas. SQL combina cada fila de la primera tabla con cada fila de la segunda.

mysql> SELECT c.first_name, c.last_name, a.address
 -> FROM customer c JOIN address a;
+------------+-----------+----------------------+
| first_name | last_name | address |
+------------+-----------+----------------------+
| MARY | SMITH | 47 MySakila Drive |
| PATRICIA | JOHNSON | 47 MySakila Drive |
| LINDA | WILLIAMS | 47 MySakila Drive |
...
| FREDDIE | DUGGAN | 1325 Fukuyama Street |
| WADE | DELVALLE | 1325 Fukuyama Street |
| AUSTIN | CINTRON | 1325 Fukuyama Street |
+------------+-----------+----------------------+
361197 rows in set (0.03 sec)

El resultado tiene 361,197 filas porque customer tiene 599 registros y address tiene 603: 599 * 603 = 361197. Normalmente esto indica que falta una condición ON.

Warning

Un JOIN sin condición explícita puede multiplicar el volumen de datos y degradar el rendimiento. Revisa siempre que exista una relación clara entre las tablas.

Inner Join

El INNER JOIN retorna solo las filas que tienen coincidencia en ambas tablas según la condición definida en ON.

mysql> SELECT c.first_name, c.last_name, a.address
 -> FROM customer c JOIN address a
 -> ON c.address_id = a.address_id;
+-------------+--------------+----------------------------------------+
| first_name | last_name | address |
+-------------+--------------+----------------------------------------+
| MARY | SMITH | 1913 Hanoi Way |
| PATRICIA | JOHNSON | 1121 Loja Avenue |
| LINDA | WILLIAMS | 692 Joliet Street |
...
| FREDDIE | DUGGAN | 1103 Quilmes Boulevard |
| WADE | DELVALLE | 1331 Usak Boulevard |
| AUSTIN | CINTRON | 1325 Fukuyama Street |
+-------------+--------------+----------------------------------------+
599 rows in set (0.00 sec)

Aunque muchos motores interpretan JOIN como INNER JOIN, escribirlo explícitamente mejora la legibilidad cuando aparecen otros tipos de unión.

SELECT c.first_name, c.last_name, a.address
FROM customer c INNER JOIN address a
 ON c.address_id = a.address_id;

Unir 3 o más tablas

Para unir más de dos tablas, repetimos el patrón: otro INNER JOIN y otra condición ON.

mysql> SELECT c.first_name, c.last_name, ct.city
 -> FROM customer c
 -> INNER JOIN address a
 -> ON c.address_id = a.address_id
 -> INNER JOIN city ct
 -> ON a.city_id = ct.city_id;
+-------------+--------------+----------------------------+
| first_name | last_name | city |
+-------------+--------------+----------------------------+
| JULIE | SANCHEZ | A Corua (La Corua) |
| PEGGY | MYERS | Abha |
| TOM | MILNER | Abu Dhabi |
...
| BYRON | BOX | Zhezqazghan |
| GUY | BROWNLEE | Zhoushan |
| RONNIE | RICKETTS | Ziguinchor |
+-------------+--------------+----------------------------+
599 rows in set (0.03 sec)

Info

SQL es declarativo: describes qué resultado necesitas y el optimizador decide cómo ejecutarlo. El orden textual de las tablas no necesariamente define el orden físico del plan.

Subqueries como tablas

Una subquery puede actuar como tabla derivada dentro de un JOIN.

SELECT c.first_name, c.last_name, addr.address, addr.city
 -> FROM customer c
 -> INNER JOIN
 -> (SELECT a.address_id, a.address, ct.city
 -> FROM address a
 -> INNER JOIN city ct
 -> ON a.city_id = ct.city_id
 -> WHERE a.district = 'California'
 -> ) addr
 -> ON c.address_id = addr.address_id;
+------------+-----------+------------------------+----------------+
| first_name | last_name | address | city |
+------------+-----------+------------------------+----------------+
| PATRICIA | JOHNSON | 1121 Loja Avenue | San Bernardino |
| BETTY | WHITE | 770 Bydgoszcz Avenue | Citrus Heights |
| ALICE | STEWART | 1135 Izumisano Parkway | Fontana |
...
| JACOB | LANCE | 1866 al-Qatif Avenue | El Monte |
| RENE | MCALISTER | 1895 Zhezqazghan Drive | Garden Grove |
+------------+-----------+------------------------+----------------+
9 rows in set (0.00 sec)

Aquí addr contiene direcciones de California junto con su ciudad, y luego se une con customer mediante address_id.

Misma tabla dos veces

Algunas consultas necesitan aplicar condiciones distintas sobre la misma entidad. Para eso usamos alias diferentes, incluso si la tabla física es la misma.

mysql> SELECT f.title
 -> FROM film f
 -> INNER JOIN film_actor fa1
 -> ON f.film_id = fa1.film_id
 -> INNER JOIN actor a1
 -> ON fa1.actor_id = a1.actor_id
 -> INNER JOIN film_actor fa2
 -> ON f.film_id = fa2.film_id
 -> INNER JOIN actor a2
 -> ON fa2.actor_id = a2.actor_id
 -> WHERE (a1.first_name = 'CATE' AND a1.last_name = 'MCQUEEN')
 -> AND (a2.first_name = 'CUBA' AND a2.last_name = 'BIRCH');
+------------------+
| title |
+------------------+
| BLOOD ARGONAUTS |
| TOWERS HURRICANE |
+------------------+
2 rows in set (0.00 sec)

Esta consulta busca películas donde participaron ambos actores. Si declaramos la tabla una sola vez y usamos OR, el significado cambia: buscamos películas donde participó cualquiera de los dos.

mysql> SELECT f.title
 -> FROM film f
 -> INNER JOIN film_actor fa
 -> ON f.film_id = fa.film_id
 -> INNER JOIN actor a
 -> ON fa.actor_id = a.actor_id
 -> WHERE ((a.first_name = 'CATE' AND a.last_name = 'MCQUEEN')
 -> OR (a.first_name = 'CUBA' AND a.last_name = 'BIRCH'));
+----------------------+
| title |
+----------------------+
| ATLANTIS CAUSE |
| BLOOD ARGONAUTS |
| COMMANDMENTS EXPRESS |
...
| VOLCANO TEXAS |
| WATERSHIP FRONTIER |
+----------------------+
54 rows in set (0.00 sec)

Self join

Un self join ocurre cuando una tabla se une consigo misma. Es común en relaciones autorreferenciales: empleados y managers, categorías padre e hijas, o películas y precuelas.

mysql> SELECT f.title, f_prnt.title prequel
 -> FROM film f
 -> INNER JOIN film f_prnt
 -> ON f_prnt.film_id = f.prequel_film_id
 -> WHERE f.prequel_film_id IS NOT NULL;
+-----------------+--------------+
| title | prequel |
+-----------------+--------------+
| FIDDLER LOST II | FIDDLER LOST |
+-----------------+--------------+
1 row in set (0.00 sec)

f representa la película actual y f_prnt representa la película relacionada como precuela. Los alias son obligatorios para evitar ambigüedad.

Teoría de conjuntos

SQL también trabaja con conjuntos completos de filas. Estas operaciones combinan resultados de múltiples consultas, siempre que las columnas sean compatibles.

La unión combina los elementos de A y B.

La intersección conserva únicamente los elementos presentes en ambos conjuntos.

La diferencia retorna los elementos de A que no están en B.

Note

Para aplicar operaciones de conjuntos, ambas consultas deben retornar el mismo número de columnas y columnas compatibles por posición.

UNION

UNION combina resultados y elimina duplicados. UNION ALL conserva todos los registros, por lo que suele ser más eficiente cuando no necesitas deduplicar.

mysql> SELECT 'CUST' typ, c.first_name, c.last_name
 -> FROM customer c
 -> UNION ALL
 -> SELECT 'ACTR' typ, a.first_name, a.last_name
 -> FROM actor a;
+------+------------+-------------+
| typ | first_name | last_name |
+------+------------+-------------+
| CUST | MARY | SMITH |
| CUST | PATRICIA | JOHNSON |
| CUST | LINDA | WILLIAMS |
...
| ACTR | MARY | KEITEL |
| ACTR | JULIA | FAWCETT |
| ACTR | THORA | TEMPLE |
+------+------------+-------------+
799 rows in set (0.00 sec)

Si duplicamos la misma consulta contra actor, UNION ALL devuelve dos copias de cada fila.

mysql> SELECT 'ACTR' typ, a.first_name, a.last_name
 -> FROM actor a
 -> UNION ALL
 -> SELECT 'ACTR' typ, a.first_name, a.last_name
 -> FROM actor a;
+------+-------------+--------------+
| typ | first_name | last_name |
+------+-------------+--------------+
| ACTR | PENELOPE | GUINESS |
| ACTR | NICK | WAHLBERG |
| ACTR | ED | CHASE |
...
| ACTR | MARY | KEITEL |
| ACTR | JULIA | FAWCETT |
| ACTR | THORA | TEMPLE |
+------+-------------+--------------+
400 rows in set (0.00 sec)

Un ejemplo más claro muestra duplicados al combinar clientes y actores con patrones similares:

mysql> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE c.first_name LIKE 'J%' AND c.last_name LIKE 'D%'
 -> UNION ALL
 -> SELECT a.first_name, a.last_name
 -> FROM actor a
 -> WHERE a.first_name LIKE 'J%' AND a.last_name LIKE 'D%';
+------------+-----------+
| first_name | last_name |
+------------+-----------+
| JENNIFER | DAVIS |
| JENNIFER | DAVIS |
| JUDY | DEAN |
| JODIE | DEGENERES |
| JULIANNE | DENCH |
+------------+-----------+
5 rows in set (0.00 sec)

INTERSECT

INTERSECT retorna únicamente las filas presentes en ambos conjuntos. Dependiendo del motor, puede existir INTERSECT ALL, que conserva duplicados según sus reglas.

Es útil para encontrar coincidencias entre fuentes: identificadores compartidos, productos presentes en dos catálogos o usuarios existentes en dos procesos.

EXCEPT

EXCEPT retorna las filas del primer conjunto que no aparecen en el segundo. También puede existir EXCEPT ALL, según el motor.

Esta operación es práctica para auditoría y reconciliación de datos.

Warning

Algunos motores no implementan INTERSECT, EXCEPT o sus variantes ALL. En esos casos puedes modelar equivalentes con JOIN, NOT EXISTS o LEFT JOIN.

Reglas de operaciones de conjuntos

Las operaciones de conjuntos son estrictas: mismo número de columnas, tipos compatibles y mismo orden.

Ordenar resultados con alias válidos

Si ordenas el resultado final, usa los nombres expuestos por el primer SELECT. En este ejemplo, last_name y first_name ya no son etiquetas válidas porque fueron renombradas como lname y fname.

-- ERROR
mysql> SELECT a.first_name fname, a.last_name lname
 -> FROM actor a
 -> WHERE a.first_name LIKE 'J%' AND a.last_name LIKE 'D%'
 -> UNION ALL
 -> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE c.first_name LIKE 'J%' AND c.last_name LIKE 'D%'
 -> ORDER BY last_name, first_name;
ERROR 1054 (42S22): Unknown column 'last_name' in 'order clause'

-- WORKS
mysql> SELECT a.first_name fname, a.last_name lname
 -> FROM actor a
 -> WHERE a.first_name LIKE 'J%' AND a.last_name LIKE 'D%'
 -> UNION ALL
 -> SELECT c.first_name, c.last_name
 -> FROM customer c
 -> WHERE c.first_name LIKE 'J%' AND c.last_name LIKE 'D%'
 -> ORDER BY lname, fname;
+----------+-----------+
| fname | lname |
+----------+-----------+
| JENNIFER | DAVIS |
| JENNIFER | DAVIS |
| JUDY | DEAN |
| JODIE | DEGENERES |
| JULIANNE | DENCH |
+----------+-----------+
5 rows in set (0.00 sec)

El orden de las operaciones importa

Las uniones se evalúan según el orden y la precedencia del motor. Cuando mezcles UNION, INTERSECT y EXCEPT, usa paréntesis para expresar intención y evitar resultados ambiguos.

Reglas prácticas:

Los alias visibles provienen del primer SELECT.
UNION elimina duplicados; UNION ALL los conserva.
ORDER BY se aplica al conjunto final, salvo que uses subqueries.
El orden de operaciones puede cambiar el resultado.

Cierre

Los JOINs y las operaciones de conjuntos resuelven problemas complementarios. INNER JOIN conecta filas relacionadas; UNION, INTERSECT y EXCEPT combinan resultados compatibles.

Dominar ambos enfoques mejora la semántica de reportes, filtros e integraciones. En el siguiente artículo avanzaremos hacia Subqueries, donde veremos subconsultas para construir lógica SQL modular.

SQL: Agrupamiento y Funciones Agregadas con GROUP BY

Dacadev — Sun, 14 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una tabla empieza a acumular miles o millones de filas, consultar registros individuales deja de ser suficiente. En análisis, reportes y validaciones operativas necesitamos resumir datos: cuántas rentas hizo cada cliente, cuánto pagó en total, cuál fue el monto máximo o qué categorías concentran más actividad. Para eso usamos agrupamiento en SQL con GROUP BY y funciones agregadas como COUNT, SUM, AVG, MIN y MAX.

Este es el artículo 4 de la serie SQL. Venimos de trabajar con lógica condicional con CASE, y ahora vamos a convertir filas transaccionales en resultados agregados listos para análisis.

Note

En este artículo aprenderás a usar GROUP BY, ordenar grupos con ORDER BY, filtrar agregaciones con HAVING, contar valores distintos con DISTINCT y crear agrupaciones por una columna, múltiples columnas o expresiones.

Conceptos de agrupamiento en SQL

GROUP BY toma filas que comparten el mismo valor en una o más expresiones y las compacta en un grupo lógico. Si seleccionamos únicamente customer_id desde rental, SQL puede devolver cada cliente una sola vez:

mysql> SELECT customer_id
 -> FROM rental
 -> GROUP BY customer_id;
+-------------+
| customer_id |
+-------------+
| 1 |
| 2 |
| 3 |
| 4 |
| 5 |
| 6 |
...
| 594 |
| 595 |
| 596 |
| 597 |
| 598 |
| 599 |
+-------------+
599 rows in set (0.00 sec)

El resultado ya no representa rentas individuales, sino el conjunto de clientes que aparecen en la tabla. El siguiente paso natural es medir cuántas filas contiene cada grupo. Para eso usamos COUNT(*):

mysql> SELECT customer_id, count(*)
 -> FROM rental
 -> GROUP BY customer_id;
+-------------+----------+
| customer_id | count(*) |
+-------------+----------+
| 1 | 32 |
| 2 | 27 |
| 3 | 26 |
| 4 | 22 |
| 5 | 38 |
| 6 | 28 |
...
| 594 | 27 |
| 595 | 30 |
| 596 | 28 |
| 597 | 25 |
| 598 | 22 |
| 599 | 19 |
+-------------+----------+
599 rows in set (0.01 sec)

Info

COUNT(*) le indica a SQL que cuente todas las filas contenidas dentro de cada grupo definido por GROUP BY. No cuenta clientes únicos; cuenta filas dentro del grupo actual.

Ordenar resultados agregados con `ORDER BY`

Una agregación suele ser más útil cuando puedes priorizarla. Por ejemplo, para identificar los clientes con más rentas, ordenamos por la segunda columna del SELECT, que en este caso es count(*):

mysql> SELECT customer_id, count(*)
 -> FROM rental
 -> GROUP BY customer_id
 -> ORDER BY 2 DESC;
+-------------+----------+
| customer_id | count(*) |
+-------------+----------+
| 148 | 46 |
| 526 | 45 |
| 236 | 42 |
| 144 | 42 |
| 75 | 41 |
...
| 248 | 15 |
| 110 | 14 |
| 281 | 14 |
| 61 | 14 |
| 318 | 12 |
+-------------+----------+
599 rows in set (0.01 sec)

Tip

ORDER BY puede usar el nombre de una columna, un alias o la posición de la columna dentro del SELECT. Aun así, en consultas mantenibles suele ser más claro usar alias explícitos.

Filtrar grupos con `HAVING`

WHERE filtra filas antes de que ocurra el agrupamiento. HAVING, en cambio, filtra grupos después de calcular las agregaciones. Esta diferencia es crítica: no puedes usar WHERE count(*) >= 40 porque count(*) todavía no existe en esa fase lógica de la consulta.

Consideremos clientes con al menos 40 rentas:

mysql> SELECT customer_id, count(*)
 -> FROM rental
 -> GROUP BY customer_id
 -> HAVING count(*) >= 40;
+-------------+----------+
| customer_id | count(*) |
+-------------+----------+
| 75 | 41 |
| 144 | 42 |
| 148 | 46 |
| 197 | 40 |
| 236 | 42 |
| 469 | 40 |
| 526 | 45 |
+-------------+----------+
7 rows in set (0.01 sec)

Analicemos el flujo conceptual: FROM obtiene las filas, WHERE descarta filas individuales, GROUP BY crea grupos, las funciones agregadas calculan métricas y HAVING descarta grupos completos. Por último, ORDER BY organiza el resultado final.

Funciones agregadas comunes

Las bases de datos implementan distintas funciones agregadas, pero estas aparecen prácticamente en cualquier motor SQL:

Función	Qué devuelve
`MAX()`	El valor máximo dentro de un conjunto
`MIN()`	El valor mínimo dentro de un conjunto
`AVG()`	El promedio de los valores del conjunto
`SUM()`	La suma total de los valores del conjunto
`COUNT()`	La cantidad de valores o filas del conjunto

Sin GROUP BY, estas funciones operan sobre toda la tabla o sobre el conjunto filtrado por WHERE. Observemos un resumen global de pagos:

mysql> SELECT MAX(amount) max_amt,
 -> MIN(amount) min_amt,
 -> AVG(amount) avg_amt,
 -> SUM(amount) tot_amt,
 -> COUNT(*) num_payments
 -> FROM payment;
+---------+---------+----------+----------+--------------+
| max_amt | min_amt | avg_amt | tot_amt | num_payments |
+---------+---------+----------+----------+--------------+
| 11.99 | 0.00 | 4.200667 | 67416.51 | 16049 |
+---------+---------+----------+----------+--------------+
1 row in set (0.09 sec)

Aquí SQL devuelve una sola fila porque existe un grupo implícito: todo el resultado de payment.

Grupos implícitos vs grupos explícitos

Cuando usamos una función agregada sin GROUP BY, SQL resume todo el conjunto como un único grupo. Eso es útil para métricas globales, pero no sirve si necesitamos una métrica por cliente, actor, categoría o periodo.

Para obtener métricas por cliente, definimos el grupo explícitamente:

mysql> SELECT customer_id,
 -> MAX(amount) max_amt,
 -> MIN(amount) min_amt,
 -> AVG(amount) avg_amt,
 -> SUM(amount) tot_amt,
 -> COUNT(*) num_payments
 -> FROM payment
 -> GROUP BY customer_id;
+-------------+---------+---------+----------+---------+--------------+
| customer_id | max_amt | min_amt | avg_amt | tot_amt | num_payments |
+-------------+---------+---------+----------+---------+--------------+
| 1 | 9.99 | 0.99 | 3.708750 | 118.68 | 32 |
| 2 | 10.99 | 0.99 | 4.767778 | 128.73 | 27 |
| 3 | 10.99 | 0.99 | 5.220769 | 135.74 | 26 |
| 4 | 8.99 | 0.99 | 3.717273 | 81.78 | 22 |
| 5 | 9.99 | 0.99 | 3.805789 | 144.62 | 38 |
| 6 | 7.99 | 0.99 | 3.347143 | 93.72 | 28 |
...
| 594 | 8.99 | 0.99 | 4.841852 | 130.73 | 27 |
| 595 | 10.99 | 0.99 | 3.923333 | 117.70 | 30 |
| 596 | 6.99 | 0.99 | 3.454286 | 96.72 | 28 |
| 597 | 8.99 | 0.99 | 3.990000 | 99.75 | 25 |
| 598 | 7.99 | 0.99 | 3.808182 | 83.78 | 22 |
| 599 | 9.99 | 0.99 | 4.411053 | 83.81 | 19 |
+-------------+---------+---------+----------+---------+--------------+
599 rows in set (0.04 sec)

La regla práctica es directa: cualquier columna no agregada en el SELECT debe representar la granularidad del resultado y, por lo tanto, debe estar en el GROUP BY.

Warning

Algunos motores permiten seleccionar columnas que no están agrupadas ni agregadas, pero el resultado puede ser ambiguo o depender de configuraciones del motor. Para consultas portables y correctas, declara explícitamente la granularidad.

Contar valores distintos con `COUNT(DISTINCT ...)`

COUNT(*) cuenta filas. COUNT(columna) cuenta valores no nulos de esa columna. COUNT(DISTINCT columna) cuenta valores únicos, ignorando duplicados.

Esto permite diferenciar entre el número de pagos registrados y el número de clientes distintos que hicieron pagos:

mysql> SELECT COUNT(customer_id) num_rows,
 -> COUNT(DISTINCT customer_id) num_customers
 -> FROM payment;
+----------+---------------+
| num_rows | num_customers |
+----------+---------------+
| 16049 | 599 |
+----------+---------------+
1 row in set (0.01 sec)

Observemos que num_rows refleja eventos de pago, mientras num_customers refleja entidades únicas. Esa distinción evita errores frecuentes en reportes, especialmente cuando mezclamos métricas transaccionales con métricas de negocio.

Generar grupos según la granularidad requerida

La calidad de una consulta agregada depende de elegir la granularidad correcta. No es lo mismo agrupar por cliente, por cliente y mes, por actor y clasificación, o por una expresión derivada de una fecha.

Agrupamiento por una columna

Agrupar por una sola columna es el caso base. En este ejemplo obtenemos cuántas películas tiene asociadas cada actor:

mysql> SELECT actor_id, count(*)
 -> FROM film_actor
 -> GROUP BY actor_id;
+----------+----------+
| actor_id | count(*) |
+----------+----------+
| 1 | 19 |
| 2 | 25 |
| 3 | 22 |
| 4 | 22 |
...
| 197 | 33 |
| 198 | 40 |
| 199 | 15 |
| 200 | 20 |
+----------+----------+
200 rows in set (0.11 sec)

Info

En este resultado cada fila representa un actor y el conteo de películas en las que participa. La consulta ya no describe relaciones individuales actor-película, sino un resumen por actor.

Agrupamiento por múltiples columnas

En algunos casos necesitamos generar grupos que combinen más de una columna. Por ejemplo, contar cuántas películas tiene cada actor por clasificación (G, PG, PG-13, R, NC-17):

mysql> SELECT fa.actor_id, f.rating, count(*)
 -> FROM film_actor fa
 -> INNER JOIN film f
 -> ON fa.film_id = f.film_id
 -> GROUP BY fa.actor_id, f.rating
 -> ORDER BY 1,2;
+----------+--------+----------+
| actor_id | rating | count(*) |
+----------+--------+----------+
| 1 | G | 4 |
| 1 | PG | 6 |
| 1 | PG-13 | 1 |
| 1 | R | 3 |
| 1 | NC-17 | 5 |
| 2 | G | 7 |
| 2 | PG | 6 |
| 2 | PG-13 | 2 |
| 2 | R | 2 |
| 2 | NC-17 | 8 |
...
| 199 | G | 3 |
| 199 | PG | 4 |
| 199 | PG-13 | 4 |
| 199 | R | 2 |
| 199 | NC-17 | 2 |
| 200 | G | 5 |
| 200 | PG | 3 |
| 200 | PG-13 | 2 |
| 200 | R | 6 |
| 200 | NC-17 | 4 |
+----------+--------+----------+
996 rows in set (0.01 sec)

Aquí la granularidad ya no es “actor”, sino “actor + clasificación”. Cada combinación única genera su propio grupo. Esta técnica es la base para reportes multidimensionales y pivotes posteriores en herramientas de BI.

Agrupamiento mediante expresiones

GROUP BY no está limitado a columnas físicas. También puede agrupar por expresiones, funciones o transformaciones calculadas. Esto es especialmente útil con fechas.

El siguiente ejemplo agrupa rentas por año:

mysql> SELECT extract(YEAR FROM rental_date) year,
 -> COUNT(*) how_many
 -> FROM rental
 -> GROUP BY extract(YEAR FROM rental_date);
+------+----------+
| year | how_many |
+------+----------+
| 2005 | 15862 |
| 2006 | 182 |
+------+----------+
2 rows in set (0.01 sec)

En lugar de agrupar por cada rental_date exacto, reducimos la fecha al año con EXTRACT(YEAR FROM rental_date). El resultado responde una pregunta distinta: volumen anual, no eventos individuales.

Buenas prácticas al trabajar con `GROUP BY`

Para mantener consultas claras y confiables, considera estas reglas:

Define primero la granularidad: una fila por cliente, por cliente y mes, por actor y rating, etc.
Usa alias descriptivos para agregaciones: num_payments, total_amount, avg_amount.
Aplica WHERE para filtrar filas antes de agrupar y HAVING para filtrar grupos.
Evita depender de posiciones como ORDER BY 2 en consultas de producción si un alias mejora la legibilidad.
Verifica si necesitas contar filas (COUNT(*)), valores no nulos (COUNT(columna)) o valores únicos (COUNT(DISTINCT columna)).

Conclusión

GROUP BY cambia la forma en que lees una tabla: pasas de inspeccionar filas individuales a construir resúmenes por la granularidad que necesita tu análisis. Combinado con funciones agregadas, HAVING, DISTINCT y expresiones, se convierte en una herramienta central para reportes, dashboards y validaciones de datos.

En el siguiente artículo de la serie vamos a conectar datos distribuidos entre tablas con consultas a múltiples tablas usando JOINs.

SQL: Lógica Condicional con la Expresión CASE

Dacadev — Thu, 11 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando una consulta necesita clasificar registros, calcular valores derivados o protegerse de casos límite, la lógica condicional en SQL evita mover decisiones simples a la capa de aplicación. Después de trabajar con filtrado de datos con WHERE, el siguiente paso natural es usar la expresión CASE para transformar resultados directamente dentro del query.

Note

En este artículo analizaremos cómo usar CASE en SQL con condiciones múltiples, validaciones de existencia, protección contra división por cero, actualizaciones condicionales y manejo explícito de valores NULL.

La expresión CASE cumple un rol similar a if / else if / else o switch / case en lenguajes de programación. Su valor está en que opera dentro del motor de base de datos: puedes derivar columnas, etiquetar estados y condicionar cálculos sin postprocesar cada fila en tu backend.

Observemos un primer ejemplo directo. A partir de una columna active, convertimos 1 y 0 en etiquetas más legibles:

mysql> SELECT first_name, last_name,
 -> CASE
 -> WHEN active = 1 THEN 'ACTIVE'
 -> ELSE 'INACTIVE'
 -> END activity_type
 -> FROM customer;
+-------------+--------------+---------------+
| first_name | last_name | activity_type |
+-------------+--------------+---------------+
| MARY | SMITH | ACTIVE |
| PATRICIA | JOHNSON | ACTIVE |
| LINDA | WILLIAMS | ACTIVE |
| BARBARA | JONES | ACTIVE |
| ELIZABETH | BROWN | ACTIVE |
| JENNIFER | DAVIS | ACTIVE |
...
| KENT | ARSENAULT | ACTIVE |
| TERRANCE | ROUSH | INACTIVE |
| RENE | MCALISTER | ACTIVE |
| EDUARDO | HIATT | ACTIVE |
| TERRENCE | GUNDERSON | ACTIVE |
| ENRIQUE | FORSYTHE | ACTIVE |
| FREDDIE | DUGGAN | ACTIVE |
| WADE | DELVALLE | ACTIVE |
| AUSTIN | CINTRON | ACTIVE |
+-------------+--------------+---------------+
599 rows in set (0.00 sec)

La expresión CASE

La expresión CASE evalúa una o varias condiciones y retorna un valor según la primera coincidencia encontrada. En SQL, CASE no es solo una herramienta cosmética; también permite modelar reglas de negocio dentro de consultas, reportes y operaciones UPDATE.

Existen dos variantes principales:

Searched CASE: cada WHEN contiene una condición completa.
Simple CASE: se evalúa una expresión base contra valores específicos.

Info

Si ninguna condición coincide y no defines ELSE, el resultado de CASE será NULL. Conviene declarar ELSE explícitamente cuando el consumidor del dato espera una categoría estable.

Searched CASE

El Searched CASE es la forma más flexible porque cada rama puede evaluar una condición distinta. Su estructura general es:

CASE
 WHEN C1 THEN E1
 WHEN C2 THEN E2
 ...
 WHEN CN THEN EN
 [ELSE ED]
END

En este patrón, C1, C2 y CN representan condiciones booleanas. Cuando una condición se cumple, CASE retorna su expresión asociada (E1, E2, EN) y deja de evaluar las siguientes ramas.

Analicemos una clasificación de categorías de películas:

CASE
 WHEN category.name IN ('Children','Family','Sports','Animation')
 THEN 'All Ages'
 WHEN category.name = 'Horror'
 THEN 'Adult'
 WHEN category.name IN ('Music','Games')
 THEN 'Teens'
 ELSE 'Other'
END

Esta variante permite mezclar operadores como IN, =, comparaciones numéricas, subconsultas y funciones. También se puede usar para evitar cálculos innecesarios en ciertas filas.

Consideremos el siguiente caso: si un cliente está inactivo, queremos retornar 0; si está activo, contamos sus rentas:

mysql> SELECT c.first_name, c.last_name,
 -> CASE
 -> WHEN active = 0 THEN 0
 -> ELSE
 -> (SELECT count(*) FROM rental r
 -> WHERE r.customer_id = c.customer_id)
 -> END num_rentals
 -> FROM customer c;
+-------------+--------------+-------------+
| first_name | last_name | num_rentals |
+-------------+--------------+-------------+
| MARY | SMITH | 32 |
| PATRICIA | JOHNSON | 27 |
| LINDA | WILLIAMS | 26 |
| BARBARA | JONES | 22 |
| ELIZABETH | BROWN | 38 |
| JENNIFER | DAVIS | 28 |
...
| TERRANCE | ROUSH | 0 |
| RENE | MCALISTER | 26 |
| EDUARDO | HIATT | 27 |
| TERRENCE | GUNDERSON | 30 |
| ENRIQUE | FORSYTHE | 28 |
| FREDDIE | DUGGAN | 25 |
| WADE | DELVALLE | 22 |
| AUSTIN | CINTRON | 19 |
+-------------+--------------+-------------+
599 rows in set (0.01 sec)

Simple CASE

El Simple CASE es útil cuando todas las ramas comparan la misma expresión contra valores concretos. En lugar de repetir category.name = ..., colocamos category.name una sola vez después de CASE.

CASE category.name
 WHEN 'Children' THEN 'All Ages'
 WHEN 'Family' THEN 'All Ages'
 WHEN 'Sports' THEN 'All Ages'
 WHEN 'Animation' THEN 'All Ages'
 WHEN 'Horror' THEN 'Adult'
 WHEN 'Music' THEN 'Teens'
 WHEN 'Games' THEN 'Teens'
 ELSE 'Other'
END

Esta forma es más compacta y legible cuando la decisión depende de una única columna o expresión. Su limitación es que no permite condiciones heterogéneas por rama; para eso conviene usar Searched CASE.

Tip

Usa Simple CASE cuando estás mapeando valores discretos de una misma columna. Usa Searched CASE cuando necesitas rangos, IN, EXISTS, comparaciones entre columnas o reglas más compuestas.

Comprobar la existencia

Uno de los usos más prácticos de CASE es combinarlo con EXISTS. Esta técnica permite crear columnas tipo bandera (Y / N, true / false, 1 / 0) según la existencia de filas relacionadas.

Observemos una consulta que marca si un actor participó en películas con ciertas clasificaciones:

mysql> SELECT a.first_name, a.last_name,
 -> CASE
 -> WHEN EXISTS (SELECT 1 FROM film_actor fa
 -> INNER JOIN film f ON fa.film_id = f.film_id
 -> WHERE fa.actor_id = a.actor_id
 -> AND f.rating = 'G') THEN 'Y'
 -> ELSE 'N'
 -> END g_actor,
 -> CASE
 -> WHEN EXISTS (SELECT 1 FROM film_actor fa
 -> INNER JOIN film f ON fa.film_id = f.film_id
 -> WHERE fa.actor_id = a.actor_id
 -> AND f.rating = 'PG') THEN 'Y'
 -> ELSE 'N'
 -> END pg_actor,
 -> CASE
 -> WHEN EXISTS (SELECT 1 FROM film_actor fa
 -> INNER JOIN film f ON fa.film_id = f.film_id
 -> WHERE fa.actor_id = a.actor_id
 -> AND f.rating = 'NC-17') THEN 'Y'
 -> ELSE 'N'
 -> END nc17_actor
 -> FROM actor a
 -> WHERE a.last_name LIKE 'S%' OR a.first_name LIKE 'S%';
+------------+-------------+---------+----------+------------+
| first_name | last_name | g_actor | pg_actor | nc17_actor |
+------------+-------------+---------+----------+------------+
| JOE | SWANK | Y | Y | Y |
| SANDRA | KILMER | Y | Y | Y |
| CAMERON | STREEP | Y | Y | Y |
| SANDRA | PECK | Y | Y | Y |
| SISSY | SOBIESKI | Y | Y | N |
| NICK | STALLONE | Y | Y | Y |
| SEAN | WILLIAMS | Y | Y | Y |
| GROUCHO | SINATRA | Y | Y | Y |
| SCARLETT | DAMON | Y | Y | Y |
| SPENCER | PECK | Y | Y | Y |
| SEAN | GUINESS | Y | Y | Y |
| SPENCER | DEPP | Y | Y | Y |
| SUSAN | DAVIS | Y | Y | Y |
| SIDNEY | CROWE | Y | Y | Y |
| SYLVESTER | DERN | Y | Y | Y |
| SUSAN | DAVIS | Y | Y | Y |
| DAN | STREEP | Y | Y | Y |
| SALMA | NOLTE | Y | N | Y |
| SCARLETT | BENING | Y | Y | Y |
| JEFF | SILVERSTONE | Y | Y | Y |
| JOHN | SUVARI | Y | Y | Y |
| JAYNE | SILVERSTONE | Y | Y | Y |
+------------+-------------+---------+----------+------------+
22 rows in set (0.00 sec)

También podemos usar CASE con una subconsulta escalar. Aquí se clasifica la disponibilidad de una película según la cantidad de copias en inventario:

mysql> SELECT f.title,
 -> CASE (SELECT count(*) FROM inventory i 
 -> WHERE i.film_id = f.film_id)
 -> WHEN 0 THEN 'Out Of Stock'
 -> WHEN 1 THEN 'Scarce'
 -> WHEN 2 THEN 'Scarce'
 -> WHEN 3 THEN 'Available'
 -> WHEN 4 THEN 'Available'
 -> ELSE 'Common'
 -> END film_availability
 -> FROM film f
 -> ;
+-----------------------------+-------------------+
| title | film_availability |
+-----------------------------+-------------------+
| ACADEMY DINOSAUR | Common |
| ACE GOLDFINGER | Available |
| ADAPTATION HOLES | Available |
| AFFAIR PREJUDICE | Common |
| AFRICAN EGG | Available |
| AGENT TRUMAN | Common |
| AIRPLANE SIERRA | Common |
| AIRPORT POLLOCK | Available |
| ALABAMA DEVIL | Common |
| ALADDIN CALENDAR | Common |
| ALAMO VIDEOTAPE | Common |
| ALASKA PHANTOM | Common |
| ALI FOREVER | Available |
| ALICE FANTASIA | Out Of Stock |
...
| YOUNG LANGUAGE | Scarce |
| YOUTH KICK | Scarce |
| ZHIVAGO CORE | Scarce |
| ZOOLANDER FICTION | Common |
| ZORRO ARK | Common |
+-----------------------------+-------------------+
1000 rows in set (0.01 sec)

Errores de división por cero

La división por cero no está definida matemáticamente y los motores de base de datos deben tratarla como un caso especial. En MySQL, por ejemplo, una división directa entre cero puede retornar NULL:

mysql> SELECT 100 / 0;
+---------+
| 100 / 0 |
+---------+
| NULL |
+---------+
1 row in set (0.00 sec)

En reportes, un NULL inesperado puede contaminar cálculos posteriores o romper supuestos del consumidor. CASE permite controlar el denominador antes de ejecutar la división.

mysql> SELECT c.first_name, c.last_name,
 -> sum(p.amount) tot_payment_amt,
 -> count(p.amount) num_payments,
 -> sum(p.amount) /
 -> CASE WHEN count(p.amount) = 0 THEN 1
 -> ELSE count(p.amount)
 -> END avg_payment
 -> FROM customer c
 -> LEFT OUTER JOIN payment p
 -> ON c.customer_id = p.customer_id
 -> GROUP BY c.first_name, c.last_name;
+------------+------------+-----------------+--------------+-------------+
| first_name | last_name | tot_payment_amt | num_payments | avg_payment |
+------------+------------+-----------------+--------------+-------------+
| MARY | SMITH | 118.68 | 32 | 3.708750 |
| PATRICIA | JOHNSON | 128.73 | 27 | 4.767778 |
| LINDA | WILLIAMS | 135.74 | 26 | 5.220769 |
| BARBARA | JONES | 81.78 | 22 | 3.717273 |
| ELIZABETH | BROWN | 144.62 | 38 | 3.805789 |
...
| EDUARDO | HIATT | 130.73 | 27 | 4.841852 |
| TERRENCE | GUNDERSON | 117.70 | 30 | 3.923333 |
| ENRIQUE | FORSYTHE | 96.72 | 28 | 3.454286 |
| FREDDIE | DUGGAN | 99.75 | 25 | 3.990000 |
| WADE | DELVALLE | 83.78 | 22 | 3.808182 |
| AUSTIN | CINTRON | 83.81 | 19 | 4.411053 |
+------------+------------+-----------------+--------------+-------------+
599 rows in set (0.07 sec)

Warning

Esta técnica evita el error o el NULL, pero no siempre significa que dividir entre 1 sea semánticamente correcto. En métricas financieras o analíticas, valida si conviene retornar 0, NULL controlado o una etiqueta explícita.

Actualizaciones condicionales

CASE también puede usarse dentro de UPDATE. Esto permite modificar registros según reglas calculadas al momento de la escritura.

El siguiente ejemplo desactiva clientes activos si su última renta ocurrió hace 90 días o más; en caso contrario, mantiene el registro activo:

UPDATE customer
SET active =
 CASE
 WHEN 90 <= (SELECT datediff(now(), max(rental_date))
 FROM rental r
 WHERE r.customer_id = customer.customer_id)
 THEN 0
 ELSE 1
 END
WHERE active = 1;

Esta aproximación concentra la regla en una sola sentencia SQL. Antes de ejecutar un UPDATE de este tipo en producción, conviene probar el mismo CASE en un SELECT, revisar cuántas filas cambiarán y ejecutar la operación dentro de una transacción si el motor lo permite.

Manejo de valores NULL

Los valores NULL aparecen con frecuencia cuando usamos LEFT OUTER JOIN, porque no siempre existe una fila relacionada. CASE nos permite reemplazarlos por un valor controlado para reportes o interfaces.

SELECT c.first_name, c.last_name,
 CASE
 WHEN a.address IS NULL THEN 'Unknown'
 ELSE a.address
 END address,
 CASE
 WHEN ct.city IS NULL THEN 'Unknown'
 ELSE ct.city
 END city,
 CASE
 WHEN cn.country IS NULL THEN 'Unknown'
 ELSE cn.country
 END country
FROM customer c
 LEFT OUTER JOIN address a
 ON c.address_id = a.address_id
 LEFT OUTER JOIN city ct
 ON a.city_id = ct.city_id
 LEFT OUTER JOIN country cn
 ON ct.country_id = cn.country_id;

En varios motores también existen funciones como COALESCE, útiles para este caso específico. Aun así, CASE sigue siendo preferible cuando la lógica depende de más de una condición o cuando el valor de salida no es simplemente el primer dato no nulo.

Cierre

La expresión CASE convierte SQL en una herramienta más expresiva para preparar datos cerca de donde viven. Con ella puedes clasificar filas, derivar columnas, controlar casos límite, ejecutar actualizaciones condicionales y normalizar valores faltantes.

Como regla práctica, usa CASE para reglas de presentación, clasificación y cálculo que pertenecen naturalmente al resultado de la consulta. Si la lógica empieza a depender de múltiples procesos externos o de reglas de dominio altamente cambiantes, evalúa moverla a una capa de aplicación o a una vista bien documentada.

En el siguiente artículo de la serie vamos a trabajar con agrupamiento y funciones agregadas, donde GROUP BY, COUNT, SUM y otras funciones nos permitirán resumir datos de manera consistente.

SQL: Filtrado de Datos con la Cláusula WHERE

Dacadev — Mon, 08 Jun 2026 00:00:00 -0500

Tabla de Contenido

El filtrado de datos en SQL es una operación diaria cuando trabajas con bases relacionales: rara vez necesitas todas las filas de una tabla. La cláusula WHERE expresa condiciones precisas para reducir resultados, evitar lecturas innecesarias y alinear la consulta con la lógica de negocio. Este es el artículo #2 de la serie SQL; si necesitas repasar SELECT, FROM y el modelo general de consulta, revisa Fundamentos de SQL.

Note

Aprenderás a usar WHERE con igualdad, desigualdad, rangos, BETWEEN, IN, subconsultas, LIKE, expresiones regulares y NULL, tanto en lectura como en modificación.

La cláusula WHERE y las condiciones booleanas

La cláusula WHERE filtra filas evaluando una o más condiciones. Cada condición produce un resultado lógico que el motor de base de datos usa para decidir si una fila entra o no en el resultado final.

En la práctica, esas condiciones suelen combinar varios tipos de operadores:

Operadores de comparación: =, !=, <, >, <>, LIKE, IN, BETWEEN.
Operadores aritméticos: +, -, *, /, cuando necesitas comparar expresiones calculadas.
Operadores lógicos: AND, OR, NOT, para componer filtros más específicos.

Aunque WHERE es el punto central para filtrar filas, también existe HAVING, que se utiliza después de agrupar datos con GROUP BY. La diferencia es importante: WHERE filtra filas antes de la agregación; HAVING filtra grupos después de calcular agregados.

Condiciones de igualdad

La condición de igualdad compara una columna contra una expresión. Esa expresión puede ser un literal, un número, una fecha o incluso el resultado de una subconsulta.

title = 'RIVER OUTLAW'
fed_id = '111-11-1111'
amount = 375.25
film_id = (SELECT film_id FROM film WHERE title = 'RIVER OUTLAW')

Observemos un caso concreto usando la base de datos de ejemplo Sakila. La consulta obtiene los correos de clientes que rentaron películas el 2005-06-14:

mysql> SELECT c.email
 -> FROM customer c
 -> INNER JOIN rental r
 -> ON c.customer_id = r.customer_id
 -> WHERE date(r.rental_date) = '2005-06-14';
+---------------------------------------+
| email |
+---------------------------------------+
| CATHERINE.CAMPBELL@sakilacustomer.org |
| JOYCE.EDWARDS@sakilacustomer.org |
...
| TERRENCE.GUNDERSON@sakilacustomer.org |
+---------------------------------------+
16 rows in set (0.03 sec)

Aquí date(r.rental_date) transforma el DATETIME a fecha antes de comparar. En producción, aplicar funciones sobre columnas puede limitar el uso eficiente de índices.

Condiciones de desigualdad

La desigualdad expresa el caso contrario: queremos excluir filas que coinciden con un valor. En SQL puedes escribirla con <>, != o usando NOT según el motor y el estilo del equipo.

mysql> SELECT c.email
 -> FROM customer c
 -> INNER JOIN rental r
 -> ON c.customer_id = r.customer_id
 -> WHERE date(r.rental_date) <> '2005-06-14';

+-----------------------------------+
| email |
+-----------------------------------+
...
| AUSTIN.CINTRON@sakilacustomer.org |
| AUSTIN.CINTRON@sakilacustomer.org |
| AUSTIN.CINTRON@sakilacustomer.org |
| AUSTIN.CINTRON@sakilacustomer.org |
+-----------------------------------+
16028 rows in set (0.03 sec)

La diferencia semántica es directa: en lugar de seleccionar rentas del día indicado, excluimos ese día.

Modificación de datos con condiciones de igualdad

WHERE no solo aparece en SELECT. También es crítico en UPDATE y DELETE, donde define exactamente qué filas serán modificadas o eliminadas.

DELETE FROM rental
WHERE year(rental_date) = 2004;

DELETE FROM rental
WHERE year(rental_date) <> 2005 AND year(rental_date) <> 2006;

El primer caso elimina rentas del año 2004; el segundo elimina rentas que no pertenecen ni a 2005 ni a 2006.

Warning

Antes de ejecutar un DELETE o UPDATE con WHERE, valida la condición con un SELECT equivalente. Un filtro demasiado amplio puede modificar más filas de las esperadas.

Condiciones de rango

Para filtrar rangos puedes combinar operadores como <, <=, > y >= con AND u OR. Esto funciona con fechas, números y otros tipos comparables.

mysql> SELECT customer_id, rental_date
 -> FROM rental
 -> WHERE rental_date < '2005-05-25';
+-------------+---------------------+
| customer_id | rental_date |
+-------------+---------------------+
| 130 | 2005-05-24 22:53:30 |
| 459 | 2005-05-24 22:54:33 |
...
| 239 | 2005-05-24 23:31:46 |
+-------------+---------------------+
8 rows in set (0.00 sec)

mysql> SELECT customer_id, rental_date
 -> FROM rental
 -> WHERE rental_date <= '2005-06-16'
 -> AND rental_date >= '2005-06-14';
+-------------+---------------------+
| customer_id | rental_date |
+-------------+---------------------+
| 416 | 2005-06-14 22:53:33 |
| 516 | 2005-06-14 22:55:13 |
...
| 148 | 2005-06-15 23:20:26 |
| 237 | 2005-06-15 23:36:37 |
| 155 | 2005-06-15 23:55:27 |
| 341 | 2005-06-15 23:57:20 |
| 149 | 2005-06-15 23:58:53 |
+-------------+---------------------+
364 rows in set (0.00 sec)

Usando BETWEEN

BETWEEN permite expresar un rango con una sintaxis más compacta. El valor menor va a la izquierda, el mayor a la derecha, y ambos límites son inclusivos.

mysql> SELECT customer_id, rental_date
 -> FROM rental
 -> WHERE rental_date BETWEEN '2005-06-14' AND '2005-06-16';
+-------------+---------------------+
| customer_id | rental_date |
+-------------+---------------------+
| 416 | 2005-06-14 22:53:33 |
| 516 | 2005-06-14 22:55:13 |
...
| 148 | 2005-06-15 23:20:26 |
| 237 | 2005-06-15 23:36:37 |
| 155 | 2005-06-15 23:55:27 |
| 341 | 2005-06-15 23:57:20 |
| 149 | 2005-06-15 23:58:53 |
+-------------+---------------------+
364 rows in set (0.00 sec)

Tip

BETWEEN puede usarse con fechas, horas, números y strings. Recuerda que los límites son inclusivos, así que valida cuidadosamente rangos de tiempo cuando trabajes con columnas DATETIME.

Condiciones de pertenencia con IN

Las condiciones de pertenencia permiten verificar si un valor existe dentro de una lista. Primero, analicemos la versión con OR:

mysql> SELECT title, rating
 -> FROM film
 -> WHERE rating = 'G' OR rating = 'PG';
+---------------------------+--------+
| title | rating |
+---------------------------+--------+
| ACADEMY DINOSAUR | PG |
| ACE GOLDFINGER | G |
...
| WEDDING APOLLO | PG |
| WEREWOLF LOLA | G |
| WEST LION | G |
...
| YOUNG LANGUAGE | G |
+---------------------------+--------+
372 rows in set (0.00 sec)

La misma condición puede escribirse de forma más clara con IN:

SELECT title, rating
FROM film
WHERE rating IN ('G','PG');

También puedes combinar pertenencia y negación usando NOT IN:

SELECT title, rating
FROM film
WHERE rating NOT IN ('PG-13','R', 'NC-17');

IN mejora la legibilidad cuando comparas una columna contra múltiples valores discretos y evita repetir la misma columna.

Subconsultas dentro de IN

IN no está limitado a listas escritas manualmente. También puedes usar una subconsulta para calcular dinámicamente los valores válidos de comparación.

mysql> SELECT title, rating
 -> FROM film
 -> WHERE rating IN (SELECT rating FROM film WHERE title LIKE '%PET%');
+---------------------------+--------+
| title | rating |
+---------------------------+--------+
| ACADEMY DINOSAUR | PG |
| ACE GOLDFINGER | G |
...
| WEDDING APOLLO | PG |
| WEREWOLF LOLA | G |
| WEST LION | G |
...
| YOUNG LANGUAGE | G |
+---------------------------+--------+
372 rows in set (0.00 sec)

La subconsulta obtiene los rating de películas cuyo título contiene PET; la consulta externa recupera las películas con esos ratings.

Condiciones de coincidencia con LIKE

Las condiciones de coincidencia permiten buscar patrones de texto en lugar de valores exactos. Con LIKE, SQL ofrece dos comodines principales:

Comodín	Significado
`_`	Exactamente un carácter
`%`	Cualquier cantidad de caracteres, incluyendo cero

Consideremos este patrón: _A_T%S. Significa: un carácter cualquiera, luego A, luego un carácter cualquiera, luego T, luego cualquier secuencia, y finalmente S.

mysql> SELECT last_name, first_name
 -> FROM customer
 -> WHERE last_name LIKE '_A_T%S';
+-----------+------------+
| last_name | first_name |
+-----------+------------+
| MATTHEWS | ERICA |
| WALTERS | CASSANDRA |
| WATTS | SHELLY |
+-----------+------------+
3 rows in set (0.00 sec)

LIKE es útil para búsquedas simples. Un patrón que inicia con %, como '%PET%', suele ser más costoso porque limita el uso de índices tradicionales.

Expresiones regulares

Algunos motores permiten filtrar texto con expresiones regulares. En MySQL, por ejemplo, se usa REGEXP. Otros motores tienen variantes propias, así que siempre valida la sintaxis de tu base de datos.

mysql> SELECT last_name, first_name
 -> FROM customer
 -> WHERE last_name REGEXP '^[QY]';
+-------------+------------+
| last_name | first_name |
+-------------+------------+
| YOUNG | CYNTHIA |
| QUALLS | STEPHEN |
| QUINTANILLA | ROGER |
| YANEZ | LUIS |
| YEE | MARVIN |
| QUIGLEY | TROY |
+-------------+------------+
6 rows in set (0.16 sec)

El patrón ^[QY] indica que el apellido debe iniciar con Q o Y. Las expresiones regulares son más expresivas que LIKE, pero menos portables entre motores.

Filtrado de valores NULL

NULL es un caso especial en SQL. No representa false, cero ni una cadena vacía; representa ausencia de valor o valor desconocido. Por esa razón, no debes comparar NULL con =.

Para consultar valores nulos se usa IS NULL, y para excluirlos se usa IS NOT NULL.

mysql> SELECT rental_id, customer_id
 -> FROM rental
 -> WHERE return_date IS NULL;
+-----------+-------------+
| rental_id | customer_id |
+-----------+-------------+
| 11496 | 155 |
| 11541 | 335 |
...
| 15867 | 505 |
| 15875 | 41 |
| 15894 | 168 |
| 15966 | 374 |
+-----------+-------------+
183 rows in set (0.01 sec)

Info

NULL = NULL no se evalúa como verdadero en SQL estándar. Cuando una comparación involucra NULL, el resultado puede ser desconocido; por eso IS NULL y IS NOT NULL son operadores específicos para este caso.

Cierre

La cláusula WHERE convierte una tabla completa en un conjunto de filas relevante. Dominar igualdad, desigualdad, rangos, pertenencia, patrones y NULL te permite escribir consultas más precisas y seguras.

Como regla práctica, diseña filtros explícitos, valida condiciones destructivas con SELECT, y considera el impacto de funciones, comodines y expresiones regulares sobre los índices. En el siguiente artículo abordaremos Lógica condicional con CASE, una herramienta clave para transformar valores dentro de tus consultas.

SQL: Fundamentos de SELECT, FROM y WHERE

Dacadev — Fri, 05 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando trabajas con una base de datos relacional, la calidad del sistema depende de consultas legibles y precisas. Las sentencias básicas de SQL como SELECT, FROM y WHERE definen qué datos recuperas, desde dónde los tomas y bajo qué condiciones entran al resultado final. Este es el primer artículo de la serie de SQL.

Note

En este artículo aprenderás cómo se organiza una consulta SQL, qué rol cumplen SELECT, FROM, WHERE, GROUP BY, HAVING y ORDER BY, y cómo usar alias, tablas derivadas, tablas temporales y vistas para construir consultas más claras.

Qué es una base de datos y cómo se estructura una consulta SQL

Info

Una base de datos no es más que un conjunto de información relacionada. En SQL trabajamos sobre esa información mediante sentencias que describen qué datos queremos leer, filtrar, agrupar u ordenar.

SQL permite expresar consultas declarativas: describes el resultado esperado y el motor decide el plan de ejecución, aplica optimizaciones y devuelve un result set.

Las cláusulas principales de una consulta suelen aparecer en este orden lógico:

Cláusula	Propósito
`select`	Determina qué columnas incluir en el result set de la consulta
`from`	Identifica las tablas de las que se extraen los datos y cómo se unen
`where`	Filtra los registros no deseados
`group by`	Agrupa filas por valores de columna comunes
`having`	Filtra los grupos no deseados
`order by`	Ordena las filas del resultado final por una o más columnas

`SELECT`: definir las columnas del resultado

Tip

La cláusula SELECT determina cuáles columnas, expresiones o valores calculados se incluyen en el resultado de la consulta.

SELECT es la parte visible de la consulta. Ahí defines columnas, valores constantes, expresiones calculadas o resultados procesados por funciones integradas.

Consideremos este ejemplo usando language:

mysql> SELECT language_id,
 -> 'COMMON' language_usage,
 -> language_id * 3.1415927 lang_pi_value,
 -> upper(name) language_name
 -> FROM language;
+-------------+----------------+---------------+---------------+
| language_id | language_usage | lang_pi_value | language_name |
+-------------+----------------+---------------+---------------+
| 1 | COMMON | 3.1415927 | ENGLISH |
| 2 | COMMON | 6.2831854 | ITALIAN |
| 3 | COMMON | 9.4247781 | JAPANESE |
| 4 | COMMON | 12.5663708 | MANDARIN |
| ... | ... | ... | ... |
+-------------+----------------+---------------+---------------+
6 rows in set (0.04 sec)

Este SELECT combina una columna real, un literal, una expresión aritmética y una función. Cada expresión forma una columna del resultado.

Reglas prácticas:

Usa * solo cuando realmente necesitas todas las columnas.
Selecciona columnas específicas para reducir ruido y transferencia de datos.
Usa AS para alias explícitos en columnas calculadas o renombradas.
Aplica operaciones, funciones integradas o expresiones cuando aporte claridad.
Usa DISTINCT para eliminar duplicados según las columnas seleccionadas.

Warning

Evita usar SELECT * por defecto en consultas que respaldan APIs, reportes o procesos críticos. Cuando el esquema cambia, el resultado también cambia, y eso puede romper consumidores que esperan columnas específicas.

`FROM`: declarar el origen de los datos

Tip

La cláusula FROM define las tablas usadas por la consulta y también la forma en que esas tablas se relacionan entre sí.

FROM indica de dónde salen las filas. Puede apuntar a tablas permanentes, derivadas, temporales o vistas.

Tablas permanentes

Las tablas permanentes son creadas con CREATE TABLE: datos persistentes, definidos en el esquema y disponibles entre sesiones.

Ejemplo mínimo:

SELECT language_id, name
FROM language;

Tablas derivadas

Una tabla derivada es una subconsulta usada dentro de FROM. Vive solo durante la ejecución y permite aislar una etapa intermedia.

mysql> SELECT concat(cust.last_name, ', ', cust.first_name) full_name
 -> FROM
 -> (SELECT first_name, last_name, email
 -> FROM customer
 -> WHERE first_name = 'JESSIE'
 -> ) cust;
+---------------+
| full_name |
+---------------+
| BANKS, JESSIE |
| MILAM, JESSIE |
+---------------+
2 rows in set (0.00 sec)

La subconsulta filtra clientes llamados JESSIE. La consulta externa usa ese conjunto como cust y construye full_name.

Tablas temporales

Las tablas temporales materializan datos intermedios durante una sesión, transacción o proceso puntual.

Info

Las tablas temporales se comportan como tablas normales, pero los datos insertados desaparecen en algún momento, usualmente al cerrar la sesión de base de datos o finalizar la transacción, según el motor utilizado.

mysql> CREATE TEMPORARY TABLE actors_j
 -> (actor_id smallint(5),
 -> first_name varchar(45),
 -> last_name varchar(45)
 -> );
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO actors_j
 -> SELECT actor_id, first_name, last_name
 -> FROM actor
 -> WHERE last_name LIKE 'J%';
Query OK, 7 rows affected (0.03 sec)
Records: 7 Duplicates: 0 Warnings: 0

mysql> SELECT * FROM actors_j;
+----------+------------+-----------+
| actor_id | first_name | last_name |
+----------+------------+-----------+
| 119 | WARREN | JACKMAN |
| 131 | JANE | JACKMAN |
| 8 | MATTHEW | JOHANSSON |
| 64 | RAY | JOHANSSON |
| ... | ... | ... |
+----------+------------+-----------+
7 rows in set (0.00 sec)

Este patrón es práctico cuando un proceso reutiliza un subconjunto de datos varias veces. Conviene medir su impacto porque materializar datos tiene costo.

Vistas

Una vista es una tabla virtual creada con CREATE VIEW. Normalmente encapsula una consulta y la expone como fuente reutilizable.

mysql> CREATE VIEW cust_vw AS
 -> SELECT customer_id, first_name, last_name, active
 -> FROM customer;
Query OK, 0 rows affected (0.12 sec)

mysql> SELECT first_name, last_name
 -> FROM cust_vw
 -> WHERE active = 0;
+------------+-----------+
| first_name | last_name |
+------------+-----------+
| SANDRA | MARTIN |
| JUDITH | COX |
| SHEILA | WELLS |
| ERICA | MATTHEWS |
| HEIDI | LARSON |
| ... | ... |
| TERRANCE | ROUSH |
+------------+-----------+
15 rows in set (0.00 sec)

Las vistas encapsulan lógica compartida y pueden exponer solo ciertas columnas a consumidores internos.

Alias: mejorar legibilidad sin cambiar el modelo

Los alias permiten referenciar tablas y columnas con nombres más cortos. Esto evita redundancia y mejora la lectura, especialmente cuando hay joins o nombres de tabla largos.

Observemos este ejemplo:

SELECT c.first_name, c.last_name,
 time(r.rental_date) rental_time
FROM customer c
 INNER JOIN rental r
 ON c.customer_id = r.customer_id
WHERE date(r.rental_date) = '2005-06-14';

En este caso, customer se referencia como c y rental como r. La consulta queda compacta y cada columna mantiene un origen explícito.

`WHERE`: filtrar filas antes del resultado final

Tip

La cláusula WHERE es el mecanismo para excluir filas no deseadas del result set.

WHERE concentra buena parte de la lógica de una consulta. Ahí combinas operadores, comparaciones, funciones y paréntesis para expresar condiciones precisas.

mysql> SELECT title, rating, rental_duration
 -> FROM film
 -> WHERE (rating = 'G' AND rental_duration >= 7)
 -> OR (rating = 'PG-13' AND rental_duration < 4);
+-------------------------+--------+-----------------+
| title | rating | rental_duration |
+-------------------------+--------+-----------------+
| ALABAMA DEVIL | PG-13 | 3 |
| BACKLASH UNDEFEATED | PG-13 | 3 |
| BILKO ANONYMOUS | PG-13 | 3 |
| BLANKET BEVERLY | G | 7 |
| BORROWERS BEDAZZLED | G | 7 |
| BRIDE INTRIGUE | G | 7 |
| CASPER DRAGONFLY | PG-13 | 3 |
| ... | ... | ... |
| WAR NOTTING | G | 7 |
| WORLD LEATHERNECKS | PG-13 | 3 |
+-------------------------+--------+-----------------+
68 rows in set (0.00 sec)

La condición usa dos grupos lógicos. Los paréntesis hacen explícita la intención y reducen ambigüedad cuando se combinan AND y OR.

Warning

Cuando mezclas AND y OR, usa paréntesis aunque el motor tenga reglas de precedencia. La consulta queda más legible y disminuye el riesgo de devolver más filas de las esperadas.

`GROUP BY` y `HAVING`: agrupar datos y filtrar agregados

GROUP BY agrupa filas por valores comunes de una o más columnas y permite aplicar agregados como count, sum, avg, min o max. HAVING opera después de la agrupación: filtra grupos, no filas individuales.

mysql> SELECT c.first_name, c.last_name, count(*)
 -> FROM customer c
 -> INNER JOIN rental r
 -> ON c.customer_id = r.customer_id
 -> GROUP BY c.first_name, c.last_name
 -> HAVING count(*) >= 40;
+------------+-----------+----------+
| first_name | last_name | count(*) |
+------------+-----------+----------+
| TAMMY | SANDERS | 41 |
| CLARA | SHAW | 42 |
| ELEANOR | HUNT | 46 |
| SUE | PETERS | 40 |
| ... | ... | ... |
+------------+-----------+----------+
7 rows in set (0.03 sec)

Aquí agrupamos rentas por cliente y dejamos solo clientes con 40 o más rentas. WHERE count(*) >= 40 no aplica porque WHERE se evalúa antes de calcular agregados.

`ORDER BY`: ordenar el resultado final

ORDER BY define el orden de las filas devueltas. Sin esta cláusula, no debes asumir un orden estable.

mysql> SELECT c.first_name, c.last_name,
 -> time(r.rental_date) rental_time
 -> FROM customer c
 -> INNER JOIN rental r
 -> ON c.customer_id = r.customer_id
 -> WHERE date(r.rental_date) = '2005-06-14'
 -> ORDER BY c.last_name;
+------------+-----------+-------------+
| first_name | last_name | rental_time |
+------------+-----------+-------------+
| DANIEL | CABRAL | 23:09:38 |
| CATHERINE | CAMPBELL | 23:17:03 |
| HERMAN | DEVORE | 23:35:09 |
| AMBER | DIXON | 23:42:56 |
| JOYCE | EDWARDS | 23:16:26 |
| ... | ... | ... |
+------------+-----------+-------------+
16 rows in set (0.01 sec)

En este caso, el resultado queda ordenado por last_name. También puedes ordenar por múltiples columnas y controlar la dirección con ASC o DESC.

Cierre

Las cláusulas básicas de SQL forman una cadena clara: SELECT define qué mostrar, FROM de dónde leer, WHERE filtra filas, GROUP BY agrupa, HAVING filtra grupos y ORDER BY estabiliza el orden final.

En el siguiente artículo de la serie profundizaremos en Filtrado de datos con la cláusula WHERE, donde analizaremos operadores, rangos, patrones, valores nulos y composición de condiciones con más detalle.

Bases De Datos · DacaCode

SQL: Transacciones, Índices y Constraints

Qué es una transacción en SQL

Candados y concurrencia

Iniciar una transacción

Terminar una transacción

Savepoints dentro de una transacción

Índices y constraints

Creación de índices

Índices únicos

Índices multicolumna

Tipos de índices

Índices B-tree

Índices bitmap

Índices de texto

Cómo se usan los índices

Constraints: restricciones de integridad

Conclusión de la serie SQL

SQL: Vistas (Views) para Abstraer y Asegurar tus Datos

Qué es una vista

Por qué usar vistas

Seguridad de los datos

Agregar datos

Esconder complejidad

Datos distribuidos o particionados

Vistas actualizables

Actualizando vistas simples

Conclusión

SQL: Subqueries y Tipos de JOIN Avanzados

Qué es una subquery en SQL

Tipos de subqueries

Subqueries no correlacionadas

Subqueries de múltiples filas y una columna

Subqueries multicolumna

Subqueries correlacionadas

El operador EXISTS

JOINs avanzados: revisitando las uniones

Outer joins

Outer joins de tres tablas

Cross joins

Natural joins

Conclusión

SQL: Consultas a Múltiples Tablas con JOINs

Producto cartesiano

Inner Join

Unir 3 o más tablas

Subqueries como tablas

Misma tabla dos veces

Self join

Teoría de conjuntos

UNION

INTERSECT

EXCEPT

Reglas de operaciones de conjuntos

Ordenar resultados con alias válidos

El orden de las operaciones importa

Cierre

SQL: Agrupamiento y Funciones Agregadas con GROUP BY

Conceptos de agrupamiento en SQL

Ordenar resultados agregados con ORDER BY

Filtrar grupos con HAVING

Funciones agregadas comunes

Grupos implícitos vs grupos explícitos

Contar valores distintos con COUNT(DISTINCT ...)

Generar grupos según la granularidad requerida

Agrupamiento por una columna

Agrupamiento por múltiples columnas

Agrupamiento mediante expresiones

Buenas prácticas al trabajar con GROUP BY

Conclusión

SQL: Lógica Condicional con la Expresión CASE

La expresión CASE

Searched CASE

Simple CASE

Comprobar la existencia

Errores de división por cero

Actualizaciones condicionales

Manejo de valores NULL

Cierre

SQL: Filtrado de Datos con la Cláusula WHERE

Ordenar resultados agregados con `ORDER BY`

Filtrar grupos con `HAVING`

Contar valores distintos con `COUNT(DISTINCT ...)`

Buenas prácticas al trabajar con `GROUP BY`

`SELECT`: definir las columnas del resultado

`FROM`: declarar el origen de los datos

`WHERE`: filtrar filas antes del resultado final

`GROUP BY` y `HAVING`: agrupar datos y filtrar agregados

`ORDER BY`: ordenar el resultado final