06 mayo 2015

NULO es NULO

Hablemos del NULL, del "nulo", pero en MySQL. Cosas que si alguna vez las he sabido, se me habían olvidado.

Parece ser que la necesidad del nulo surgió del propio día a día que quería representar y gestionar el modelo relacional. Es muy habitual encontrarse con formularios donde falta algún dato, bien por ignorancia o por poca relevancia. Vamos, que casi da igual que lo pongas que no, no es importante. En otros casos incluso podría ser inaplicable, pongamos "color de pelo" si resulta que antes has elegido "piedra". Para eso es el nulo.

NULL es un, llamémosle, valor de difícil implementación. De hecho, no es un valor, es un estado, y un nulo no es igual a otro nulo. En clase solemos decir "no sabemos si tiene valor y, si tiene, no sabemos cuál es". En SQL se nota porque no se puede preguntar x = NULL. El nulo no se puede utilizar en comparaciones con "igual", "menor que" y todos los demás. Tenemos que utilizar un operador específico, x IS NULL o x IS NOT NULL.

Para liarla más autores hay que dicen que, precisamente el nulo, es el mayor error de Codd al definir el modelo relacional (1). Y Codd dice que sin los nulos no hay modelo relacional. Lo cierto es que su aplicación más clara es en las claves ajenas donde la existencia de un nulo se interpreta como ausencia de relación. Por eso la mayoría de los sistemas de gestión de bases de datos lo tratan como "ausencia de valor" o "sin valor". Esto hace las cosas más fáciles ya que el nulo solo puede trabajarse con el mencionado operador IS.

29 abril 2015

Servidor MySQL denuncia a sus usuarios por maltrato

O eso ocurriría si el pobre pudiera hablar. Es recurrente, ocurre todos los años en cuanto llegan los ejercicios que hemos llamado de "aritmética de columna". Hay un ejercicio especialmente gracioso:

T09.017- Cantidad de artículos que no son ni memoria, ni tv, ni objetivo, ni cámara ni pack.
Pongámonos en situación. Los artículos de TiendaOnLine están catalogados en grandes familias como televisores, cámaras, objetivos, etc. Estructuralmente lo que nos encontramos son códigos de artículo que aparecen en una de esas tablas, además de ciertos atributos propios, no comunes a todos los artículos. Todos tienen marca y precio de venta al público (PVP) pero solo los televisores tienen, además, "panel". Es lo que se llama una "generalización": los televisores son artículos, los objetivos son artículos... Por eso hay una tabla general "artículo" y otra, especializada, para cada familia. Estas últimas tienen una clave ajena hacia "artículo" que es, al mismo tiempo, clave primaria de la tabla especializada.

El resultado en nuestra base de datos es cero, todos los artículos están catalogados en alguna de esas familias. Dicho de otra forma, todos los códigos de artículo aparecen en dos de esas tablas, en la de "artículo" —ahí están todos— y en una de las especializadas —o en "tv", o en "objetivo", o en "memoria"...—. Esto es así simplemente por los datos con que hemos cargado la base de datos, con otros datos el resultado podría ser distinto.

Lo gracioso no es esto sino que todos los años MySQL se nos queja de que más de uno intenta

select count(*)
from articulo, camara, objetivo, pack, memoria, tv
where articulo.cod!=camara.cod
and articulo.cod!=tv.cod
and articulo.cod!=pack.cod
and articulo.cod!=objetivo.cod
and articulo.cod!=memoria.cod



Esta barbaridad debería poderse cobrar en forma de sanción administrativo-penal.

Vamos a hacerlo más simple, "cantidad de artículos que no son memoria". Partimos del siguiente estado de base de datos: