Cuando LIKE no basta: búsquedas avanzadas usando RLIKE en MySQL

AUTOR: Yeray Alcala Paz

Uno de los operadores más básicos de MySQL es LIKE, que nos permite comprobar si un texto verifica un cierto patrón, gracias al uso de caracteres comodín % y _. Pero… ¿y si necesitamos algo más?

¿Se puede agrupar por rangos de valores?

Esta mañana en clase, me habéis preguntado si al agrupar podemos utilizar rangos de valores para definir los grupos. Mi respuesta ha sido que no. Los grupos se definen en base a valores concretos de los componentes del criterio de agrupación. Pero podemos aplicar un truquillo para conseguir esa agrupación por rangos (a esta técnica se llama SQL Binning).

Sumar días a una fecha en MySQL

AUTOR: Ariel Ibáñez Gabás

En ocasiones, algunas consultas u operaciones LMD deben sumar (o restar) días a una fecha concreta, que normalmente es el campo de una tabla como la fecha de nacimiento, de contratación, de alta en el sitio web...

Aunque lo más natural para operar con este tipo de datos sea pensar que el operador '+' va a sumar correctamente los días a una fecha, esto no es correcto y generará resultados inesperados y erróneos si se trabaja con MySQL como SGBD. Esta limitación no es un problema si se utilizan otros gestores, que sí lo permiten.

Usar alias con significado

AUTORA: Ana Ramos Clavijo

Usar alias para tablas en el from de una consulta es una herramienta imprescindible que podemos aprovechar siempre que utilizamos una base de datos. A pesar de su utilidad puede llegar a confundir; debemos aprender a usar alias otorgándoles significado y, a la vez, hacer que sean cortos y entendibles.

Cuidado con not in y los valores nulos

Cuando usamos el operador not in sobre el resultado de una subconsulta es necesario ser precavido ante la posible presencia de valores nulos en ese resultado.

Uso de CASE como si fuese GROUP BY

AUTORA: María González García

Al realizar cálculos sobre agrupaciones de tuplas según los valores de un campo, podemos plantearnos esta cuestión: ¿deberíamos utilizar GROUP BY o CASE?

Aunque GROUP BY es generalmente la opción más directa y eficiente para agrupar y calcular datos, existen situaciones donde CASE puede ofrecer una flexibilidad única y su uso se vuelva necesario. Por otra parte, dicha elección también puede depender de las necesidades visuales o preferencias de formato del resultado a obtener, ya que cada método ofrece una presentación y organización de los datos distinta.

Abusos de la estructura case de SQL

AUTOR: Mateo Domínguez Gómez

El uso de la estructura CASE en consultas SQL puede ser una herramienta poderosa para obtener diferentes resultados en función de un conjunto de condiciones. Sin embargo, en ocasiones se puede abusar de su uso, lo que puede llevar a código menos eficiente o incluso incorrecto.

En esta entrada, exploraremos tres ejemplos comunes de abuso de la estructura CASE y cómo evitarlos para mejorar la claridad y eficiencia de nuestras consultas.

Condiciones en outer join (on vs where)

Una de las complicaciones al aplicar un outer join es determinar en qué lugar debemos colocar las condiciones de filtrado para ni perder tuplas que deberían aparecer en el resultado, ni hacer que en éste aparezcan tuplas de más.

Evitar datos repetidos si no se puede usar distinct

A veces ocurre que en el resultado de una consulta obtenemos datos repetidos que surgen del emparejamiento de tuplas de dos tablas (o de la misma tabla si se hace un auto-join). No me refiero a tuplas repetidas (que se evitarían con un distinct) sino a valores repetidos en diferentes columnas del resultado. Pongamos un ejemplo.

Join sin usar foreign key

Muchas veces creéis necesario realizar los joins usando exclusivamente campos que sean claves foráneas entre las tablas, o dicho de otra manera más informal, que hay que usar "los caminitos" que se ven en los diagramas del esquema de la BD). No es necesario; incluso, a veces, hacerlo puede suponer emplear tablas innecesarias que penalizan el rendimiento. Veámoslo en el siguiente ejemplo.

Usar in te puede ahorrar trabajo

El operador in sirve para comprobar la pertenencia de un valor a un conjunto de valores. Su uso es equivalente a una serie de comparaciones individuales concatenadas con operadores or... pero es mucho más corto de escribir.

Restando fechas: formas de calcular la edad

Es obvio que la edad actual de una persona se calcula restando la fecha del momento y la fecha de nacimiento. Hay varias formas de hacerlo, cada una con una mayor precisión que la anterior. En este artículo vamos a utilizar las funciones para restar fechas y obtener componentes de fechas de MySQL (aquí hay una lista de esas funciones). Para aplicar estas ideas a otros gestores de BD, debes buscar las funciones equivalentes en esos gestores.

Distinct no es una función

Es muy habitual ver consultas que emplean la cláusula distinct como si fuese una función, es decir, encerrando entre paréntesis un campo como si fuese un parámetro de invocación a la función.

Las funciones de agregación no pueden aparecer en el where

Es habitual encontrarse consultas como la siguiente: hallar los artículos con el precio más bajo de entre los contenidos en una tabla. Para resolverla podríamos tener la tentación de ejecutar un select SQL, que incluye funciones de agregación en el where, y, por tanto, es incorrecta:

Notación de comparación de tupla para simplificar consultas

SQL permite comparar varias columnas con una única operación, usando la notación de tupla; p.ej., (nombre, apellido) = ('Fran', 'García'). Se trata de una notación muy compacta y útil, que puede llegar a simplificar mucho algunas consultas que requieren de varias subconsultas sobre la misma tabla. Veamos un ejemplo.

FULL OUTER JOIN en MySQL

A diferencia de otros SGBD como SQL Server, Oracle o PostgreSQL, MySQL no implementa la operación FULL OUTER JOIN (me refiero a la versión 8.0.32 e inferiores). Sí implementa LEFT OUTER JOIN y RIGHT OUTER JOIN.

Para realizar esta operación en MySQL hay que hacer la UNION de ambos OUTER JOIN laterales. Pero la explicación requiere aclarar algún matiz adicional que encontrarás descrito a continuación

En las instrucciones update o delete también se pueden hacer joins

Del mismo modo que ante una consulta que requiera datos de varias tablas recurrimos a join para obtener la solución, en una instrucción update o delete también podemos hacerlo. Lo que sigue utiliza la sintaxis propia de MySQL, pero otros SGBD (como SQL Server o PostgreSQL) también permiten hacerlo de forma similar.

Para actualizar un campo usando su antiguo valor no hace falta una subconsulta

Sabemos que en las instrucciones LMD (insert, update, delete) podemos usar subconsultas. Pero en ocasiones, como cuando se quiere actualizar el valor de un campo a partir del valor anterior del mismo, no es conveniente emplearlas. Lo único que conseguimos es complicar la instrucción y penalizar el rendimiento en su ejecución.

Qué hacer cuando una modificación requiere consultar la tabla que se está modificando

En ocasiones, para modificar una tabla (con update, insert, delete), necesitamos consultar algún dato de la la propia tabla para usarlo en la instrucción de modificación. En MySQL esto no es posible, salvo que emplees este truco.

Ejercicio típico: entidades que se relacionan con dos (o más) entidades de otro tipo

Un tipo de consulta habitual es la que pretende obtener datos de una entidad de un tipo dado (entidad A) que se relacionan con varias (dos o más) de otra entidad de otro tipo (entidad B). P.ej.: alumnos (A) que están matriculados en dos asignaturas (B) dadas, proyectos (A) en los que trabajan al mismo tiempo dos empleados (B) dados, etc.