A vueltas con UPDATE

Más pronto o más tarde nos encontraremos con esta situación. Aprovecho la base de datos EJEMPLO y su tabla PROFESORES de la asignatura —y de paso enlazo FBDdocs—. Si quieres seguir la historia que voy a contar, nada más fácil que usar tu base de datos propia y hacer

create table profesores (select * from ejemplo.profesores)

Ahora tienes una copia de esa tabla y puedes modificar sus filas.

Si de contar filas se trata

Resulta que esa página del manual de MySQL nunca la he visitado. O no le he hecho mucho caso.

En una aplicación PHP quería limitar el número de filas que devuelve una consulta pero, al mismo tiempo, saber cuántas filas obtendría sin esa limitación. Esto es

select ... limit 100

El problema es contar. Si hago la consulta dos veces, una sin límite para contar y otra limitada para mostrar el resultado, el cliente debe esperar a recibir todas las filas de la tabla y después otras 100.

Sí, para eso está el select count() ... Pero ocurre una cosa curiosa. Por la naturaleza de mi programa no puedo saber cuál es esa consulta así que lo primero que piensas es en convertirla en subconsulta:

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.