Varios autores coinciden con la experiencia de quienes han trabajado con valores nulos: no usar valores nulos ([DAT07], [CEL10], [COR09] y [ELM07], entre otros). Algunos motivos son:
- Dos valores nulos no son iguales ("nulo" significa realmente "indefinido") por tanto no son comparables.
- Las bases de datos necesitan espacio adicional para almacenar un valor nulo.
- Las aplicaciones deben tener lógica extra para trabajar con campos nulos.
- Puede producir problemas a la hora de calcular, comparar, ordenar y agrupar.
- Provoca resultados no esperados con las cláusulas NOT EXIST y NOT IN.
Como alternativa, es preferible utilizar valores equivalentes a nulos. Por ejemplo, la cadena vacía puede considerarse, a todos los efectos, como un valor nulo (no suele haber diferencia entre que el usuario no rellene un campo o lo haga con la cadena vacía); si bien el significado no es el mismo, a la larga suele carecer de importancia. De igual modo, -1 puede ser un buen sustituto del nulo cuando se esperan valores naturales.
Sólo es interesante utilizar nulos en tipos de campo sobre los que no se pueda obtener un valor sustituto de aquél. Experimentalmente, los campos de tipo fecha y hora son los posibles candidatos a esto, y sólo debería permitirse cuando realmente deba ser un campo nulo.
[DAT07] C. J. Date. Logic and databases: the roots of the relational theory. Trafford, Victoria (Canadá), 2007.
[CEL10] J. Celko. Joe Celko's data, measurements and standards in SQL. Morgan Kaufmann, Burlington, 2010.
[COR09] C. Coronel, S. Morris, P. Rob. Database systems: design, implementation, and management, 9th ed. Cengege Learning, Boston, 2011.
[ELM07] R. Elmasri, S. Navathe. Fundamentals of database systems. Pearson / Addison Wesley, 2007.
