El tema que voy a desarrollar no es una mala práctica concreta, si no un conjunto de malos usos que tienen que ver con la misma fuente, la mala definición de los tipos de datos almacenados en la base de datos, en concreto en este caso con la reestricción de determinar si un dato puede ser un nulo en un registro.
El uso de las claíºsulas NULL y NOT NULL a la hora de definir un campo de la base de datos tiene una misión muy concreta, simple y a la vez fundamental en la definición de un modelo relacional: Definir si un determinado valor puede permanecer con un estado nulo en un determinado registro.
Esto resulta obvio en la mayoría de los casos, por ejemplo, la clave primaria de una tabla es siempre por defecto NOT NULL, no tiene sentido que el valor que distingue de forma íºnica un registro de la tabla esté a nulo.
Una clave foránea no tiene por qué ser NOT NULL.
En otros casos resulta también obvio, aunque el error humano puede provocar que no se establece el NOT NULL y permitir que tablas del tipo Codigo – Descripción tengan el campo Descripción a NULL. Esto suele provocar efectos muy incómodos a la vista, como el típico mantenimiento que al listar los resultados nos aparece la descripción del registro vacía.
Otro caso que debemos tener en cuenta es el uso de campos NULL en los tipos de dato numéricos. Por ejemplo, si tenemos una tabla con un registro que almacena un temporizador no tenga sentido sea nulo, aunque funcionalmente esté descrito que el valor pueda no estar establecido en un momento dado. Tal vez sería mejor la combinación NOT NULL con un valor numérico por defecto, por ejemplo cero. Con lo cual nuestro temporizador partiría siempre del valor 0, evitando así por ejemplo problemas en tiempo de ejecución en nuestra aplicación (NULL * 3 = ¿?).
Saludos.
Miguel.
tienes razon
odio los null!