De null o de si sé programar o no

Publicado: junio 19, 2013 de elvenbyte en Tecnología
Etiquetas:

Una discusión con varias opiniones

No recuerdo cuándo fue la primera vez que me enfrenté a un valor null. Supongo que habrá pocos programadores que lo recuerden. Pero sí recuerdo lo que mis grandes maestros me han dicho siempre, que no es más que un ejercicio de pura lógica:

    1. Los problemas hay que atajarlos de raíz.
    2. Un null es un problema.
    3. La raíz en programación es la base de datos.
    4. Por lo tanto el null hay que tenerlo controlado, en la medida de lo posible, ya en la base de datos.

Eso no quiere decir que no haya que tener en cuenta en programación que pueda venir un null, pero nos ahorra mucho código saber que la base de datos no nos va a enviar nunca null desde un campo con tipo determinado, primitivo y concreto.

Hoy me he topado con el caso contrario. La culpa en realidad ha sido mía, por pensar que un código postal (campo de tipo texto bien definido) iba a traer, en el peor de los casos, un espacio en blanco. Pero no, traen null.

La base de datos es MySQL, la plataforma de desarrollo es Java Server Faces, todo en versiones viejas, y al que en su momento definió la base de datos, por lo visto nadie le explicó que, en MySQL, puedes asignar un valor por defecto a un campo, y este no tiene porqué ser null, precisamente.

Aquí el problema es que todo el mundo sabe, o quiere saber, y aunque me consta que mi jefe sabe lo que me decía, sigo diciendo que el problema está en la base de datos, o sea que no tendríamos porqué estar controlando casi cada línea con contenido de base de datos.

Pero siempre está la excepción, que es el argumento de la discusión: si el campo trae un null, viene vacío, y por lo tanto no ocupa espacio. Una tabla con un millón de registros, con un campo con un espacio en blanco, ocupa un byte por registro. Un millón de bytes, 1 mega para los amigos.

Aquí, como en otras discusiones, como podría ser la de cuándo romper la tercera forma normal, tenemos el dilema. ¿Merece la pena en este caso? Y si merece la pena, ¿entonces la culpa es del programador o del DBA?

Bonita discusión, pero eterna como jugar a las tres en raya, me temo.

Aún así, y para reforzar mi posición, me permito dejar un par de enlaces, a modo de argumento a mi favor:

Y con estos dos yo creo que ya hay.

comentarios
  1. Willy dice:

    El valor null existe desde 1970, cuando Edgar F. Codd introdujo la lógica ternaria en el modelo relacional de bases de datos. Esto lo hizo para poder representar el valor desconocido o ausencia de valor y diferenciarlo de cualquier otro valor.

    No es lo mismo decir el código postal del cliente es desconocido que el cliente no tiene código postal.

    Tampoco sería lo mismo decir que David ha sacado un cero en el examen a decir que David no tiene nota del examen, probablemente por no haberse presentado.

    Así que todo apunta a que cuando un campo de base de datos pueda dejarse “sin valor” tenga sentido que sea NULL, en lugar de la “ñapa” de usar un valor por defecto como la cadena vacía (para cadenas de texto) o un cero (para valores numéricos). Si existe la marca NULL en las bases de datos, con toda la lógica asociada, y conocemos cómo funciona ¿para qué usar ñapas?

    Por otro lado, si nos metemos en temas de implementación en java podemos ver que en el javadoc de la interfaz ResultSet, método getString(), se indica claramente esta casuística:
    Returns: the column value; if the value is SQL NULL, the value returned is null
    Es buena idea leer siempre la documentación del api que estemos utilizando para evitar problemas de este tipo; de verdad, ahorran mucho tiempo.

    Aquí van unas urls:
    https://en.wikipedia.org/wiki/Relational_model
    https://en.wikipedia.org/wiki/Ternary_logic
    https://en.wikipedia.org/wiki/Null_(SQL)
    http://docs.oracle.com/javase/6/docs/api/java/sql/ResultSet.html#getString(java.lang.String)
    http://memegenerator.net/instance/38902516

    Me gusta

  2. admin dice:

    Gracias, muy instructivo🙂 Voy a leerme en cuanto tenga un rato esos enlaces.

    La única observación que se me ocurre, es que la teoría está muy bien, y desde luego está para seguirla, sin duda, pero a veces tener esos valores a NULL en la base de datos, hace que tengamos que estar comprobando si nos puede llegar un valor a NULL o no por toda la aplicación. Eso es lo que realmente me fastidia a mi, y lo que sí me parece “ñaposo”.

    En realidad supongo que lo correcto es ir comprobando por el código si un campo devuelve NULL o no, pero desde luego no facilita la programación, y acabamos encontrando código !=NULL, y bloques try/catch por todo el código.
    Yo creo que es mejor la ñapa de la base de datos, que ir ensuciando el código así, pero supongo que todo es discutible.

    Ayer me argumentaban que un espacio vacío ocupa espacio, y un NULL no. Para bases de datos antiguas está claro que esto importa, pero para las de hoy en día, que son teóricamente “de alto rendimiento” no sé si realmente se iba a notar mucho.

    Me gusta

  3. Willy dice:

    Sigo sin ver cuál es el problema de hacer if (cliente.codigoPostal != null) ...
    en java para comprobar que el atributo codigoPostal haya sido inicializado.

    Tampoco entiendo por qué deberíamos encontrar los bloques try/catch que mencionas por culpa de un campo a null en base de datos. ¿Algún ejemplo?

    Me gusta

  4. admin dice:

    No creo que haya ningún problema en hacer la comparación circunstancialmente. En mi opinión el problema viene cuando tienes que hacer la comparación mucho más larga: if (cliente.codigoPostal != null && cliente.direccion != null && cliente.población != null…. etc

    El try/catch lo decía más por las NullPointerException.

    Me gusta

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s