Evitar valores nulos en las tablas

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.

Principios rectores de la docencia

Propongo lo que para mí deberían ser los principios rectores de un buen docente, y que, en mayor o menor medida, he intentado llevar a cabo durante mis años como profesor.

1. Atención: el docente debe “enganchar” a los estudiantes y tratar de garantizar su interés. Sin atención, nada de lo que se explique será útil. De esta forma, además, se facilita el siguiente principio.
2. Interacción: el docente debe conocer a sus alumnos, y éstos deben participar con frecuencia y ser invitados a expresar sus inquietudes. De esta forma, además, se facilita el siguiente principio.
3. Contenido: basándose en un temario abierto, el docente debe considerar las necesidades detectadas en o referidas por los estudiantes, con objeto de apuntalar contenido específico.

Esto no garantiza el éxito de nuestras clases, pero son un buen punto de partida.

Nombrar campos clave en las tablas

• Todas las tablas tienen un identificador entero llamado Id, salvo las tablas que representen relación N x N (x N…), cuyo uso es opcional y no necesario.
  
• Todas las claves ajenas tiene la forma Id_{Tabla} (por ejemplo, Id_Color o Id_Vehicle) u, opcionalmente, Id_{Tabla}_{semántica} (por ejemplo, Id_Team_local).
• Para mantener un criterio visual homogéneo, el orden de aparición de los campos es: clave primaria, claves ajenas y todos los demás.
• Los nombres de las tablas que representan una relación N x N (x N…) son {Tabla 1}_{Tabla 2}(_{Tabla 3}…), como por ejemplo Person_Vehicle.
• Las claves candidatas deben ser marcadas como campos de tipo índice único en el gestor de bases de datos.

Tamaño de campos de tipo cadena variables

Un criterio práctico es hacer que el tamaño de los campos de tipo carácter variable (nvarchar, por ejemplo) sea 2ⁿ, donde n es un valor dependiente de los requisitos de espacio de dicho campo. Además de establecerse un criterio homogéneo, la principal ventaja de esta norma es la de responder automáticamente a la necesidad de mayor capacidad. Así, en lugar de pasar de 100 a 110 o 150 caracteres ante el requerimiento de mayor espacio, el campo se ampliará de 128 a 256 caracteres, de forma que todo incremento solicitado asegurará un crecimiento del 100% el tamaño actual. Debido a que, como se ha dicho, este criterio se toma para cadenas de caracteres variables, no existirán problemas de memoria.