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.