Por llamarlos de alguna forma. Existen errores debidos al despiste, otros debidos a la ignorancia (en el buen sentido de la palabra, falta de conocimientos), y otros que no tienen explicación.
Hablando de tecnología, de programación, buenas prácticas, principios SOLID, conceptos como Hexagonal, DDD, TDD y un largo diccionario de términos que los que nos dedicamos a estas cosas tenemos que aprender, sí o sí. O eso parece, porque si no estamos fuera de órbita… va uno y se encuentra con formularios de registro en los que es imposible escribir el nombre de la población, ya que sobrepasa el número máximo de caracteres. ¿En serio? Lo curioso es que se pueden escribir cientos de caracteres… y luego te marca el campo en rojo, sin más explicación. He lidiado con formularios durante años, y algo que hay que entender es que hay informaciones que NO pueden abreviarse y por tanto la base de datos deberá adaptarse a las necesidades del dominio (ja, ahí no pude resistirlo…) y aceptar información más allá de lo que el diseñador de la BDD haya pensado.
El caso de las poblaciones, es que es muy fácil… Hay nomenclatores de localidades y ciudades de cualquier país del mundo. ¿Vas a trabajar sólo con localidades españolas? Pues… busca cuál es el nombre más extenso, dale aún un poco más de margen y sabrás cuál es la longitud máxima que debes tener en cuenta. Y, además, haz que el formulario reaccione y ofrezca algo de feedback al usuario para que sepa qué pasa.
Gargantilla del Lozoya y Pinilla de Buitrago (Madrid), tiene 44 caracteres. ¡Que lo sepáis, diseñadores de bases de datos! Y a mí me da error una localidad con 20 caracteres…
Al diseñar la estructura de una base de datos, sus tablas, campos, relaciones, índices, etc. debe tenerse en cuenta una serie de aspectos que damos por sentados y quizás, aplicados al caso particular sea necesario tener más información al respecto. Casos como el descrito antes son frecuentes, incluso en el ámbito de las instituciones gubernamentales, sanidad, etc. donde las gestiones online cada vez son más comunes y obligatorias. Es por tanto importante que los datos sean correctos, no se trunquen y sean almacenados y tratados sin errores. Una dirección mal descrita, un nombre de persona incompleto, un número de cuenta corriente o tarjeta de crédito erróneo dificultarán o incluso impedirán realizar un trámite o una gestión.
La dirección email, por ejemplo, ¿cuál es el número máximo de caracteres para el campo email? «Nada, esto con 128 caracteres hay suficiente…». ¿Seguro? Pues.. no. Según San Google, tendríamos lo siguiente:
Hay un límite de longitud en las direcciones de correo electrónico. Ese límite es un máximo de 64 caracteres (octetos) en la parte local (antes de la » @ «) y un máximo de 255 caracteres (octetos) en la parte del dominio (después de la «@») para una longitud total de 320 caracteres.
Mencionando a «San Google» hago referencia a que hoy día no hay excusa para no saber un dato así. Con buscarlo podemos averiguar muchísimas cosas en unos segundos.
En el pasado tendíamos [los programadores] a ajustar al máximo las longitudes de los campos (¡en ficheros!) porque el espacio de almacenamiento era muy limitado, y un caracter era un caracter (o byte). En la actualidad, no digo que haya que desperdiciar el espacio, pero gracias a tipos de datos como VARCHAR, etc. no es necesario ajustarse tanto el cinturón y es posible delegar la tarea de optimización del almacenamiento al motor de la base de datos utilizado. Aprovechar hasta el último bit era entonces reto y casi obligación, pero hoy por hoy, excepto en casos extremos, no es necesario.
Otro día, tal vez, os cuento por qué las aplicaciones de gestión de índole general deberían ser más permisivas en este aspecto, o sus diseñadores mejor formados. Desde la implantación de los valores numéricos contables a dos decimales, hay verdaderos problemas para gestionar productos y servicios cuyo coste nominal es menor que 0,01 € y que no se contemplan.
