Pues si. Me fascinan las Bases de Datos. Representan el orden y la disponibilidad de información que no siempre está presente en mi mente. Son como las muletas de la memoria. Si tuviéramos memoria perfecta e limitada las Bases de Datos serían un elemento completamente inútil.
No aspiro a disponer de la base de datos perfecta como si pudieras preguntarle por el sentido de la vida, el universo y todo lo demás y fuera a contestarte 42 sin titubear.
No, en absoluto. Mis aspiraciones se mueven en un plano mucho más modesto. Por ejemplo la agenda de direcciones. Una agenda en la que solo hay que anotar los datos una vez, nunca hay contactos repetidos y todas las asociaciones son patentes: si pepito es el marido de fulanita siempre lo sabemos al consultarla, podemos seleccionar a los que conocemos del colegio y a los que solo soportamos en el trabajo. Los datos disponibles de forma instantánea y en la medida y formato necesario.
Para aproximarse a eso hace falta algo más que saber meter datos en una ficha. En primer lugar hay que tomar decisiones. ¿Que campos usar? Si escribimos en fichas de carton pondremos nombre y dos apellidos en la primera linea, pero en una base de datos, ¿usamos uno, dos o tres campos diferentes para el nombre completo? Son decisiones de este tipo las que hacen fracasar la mayoría de las relaciones entre el público y las bases de datos.
La lógica científica dice que los datos están mejor en tres campos. Se puede responder a más preguntas como por ejemplo ¿Cuandos contactos se llaman de segundo apellido fulanez? incontestable usando solo un campo. Sin embargo la logica científica no es perezosa y la mayor parte de nosotros si. Bueno, a parte de la pereza, se trata de acabar la tarea y si nos dejamos llevar por la ortodoxia de las reglas de sistemas de bases de datos relacionales podemos llegar a detalles absurdos.
Estas normas exigen que nunca se repita un dato en una base de datos. Por ejemplo, si tienes una base de datos para tus libros, deberias tener una tabla auxliar de autores y una tabla auxiliar de editoriales. De esa forma se garantiza que el nombre de la editorial solo aparece en la tabla auxiliar, aunque tengas muchos libros de la misma editorial. Además siempre que busques por el nombre del autor sabes que aparecerán todos sus libros presentes en tu biblioteca ya que no habrás cometido el error de poner que uno es de «Cervantes, Miguel» otro de «M.Cervantes» o de «M. Cervantes» ni de «Miguel de Cervantes Saavedra» o de «Cervantes Saavedra, Miguel de»… las diferencias inapreciables para nuestra vista al repasar unas fichas de cartón son diferencias sustanciales para un programa informático. Crear tablas auxiliares nos ayuda a eliminar estas indeterminaciones. En grandes bases de datos, además ahorra enormes cantidades de tiempo y trabajo al procesador. Y espacio en el disco.
Al nivel de nuestra base de datos casera, sea la agenda, el indice de nuestros discos, sellos o libros, la verdad es que no va a suponer un problema de eficacia, pero hay que hacerse la siguiente pregunta: ¿Necesitaré hacer búsquedas por autor o editorial? si la respuesta es afirmativa en un numero suficiente de casos, hay que realizar el esfuerzo en tiempo de diseño de separar los campos. Porque hay que tener en cuenta que es mucho más fácil unir campo que separarlos. De hecho es prácticamente imposible separar nombre, primer apellido y segundo apellido en tres campos a partir de un solo campo que contenga el nombre completo salvo que se haga de forma manual. A partir de un cierto numero de registros, esa separación, más que un trabajo, es un castigo. Sin embargo la operación contraria se realiza en segundos a partir de dos instrucciones SQL aun con miles de registros.
Otro problema son las fechas indeterminadas. Un ordenador espera que le demos un día mes y año congruentes para poderlos combinar como una fecha. No solo no aceptará 30/02/2008 como una fecha sino que es imposible explicarle el concepto «marzo del 2007» o «primeros de junio de 2008» o simplemente «1987». Y eso puede suponer un problema. En muchos libros no figura la fecha excata de la edicion. No suele mencionarse en las referencias bibliográficas, donde solo se considera el año. Pero ¿que pasa con las revistas?. En muchas figura solo el mes del año. ¿La ponemos como fecha de publicación el día primero del mes? ¿Y las que salen semanales? ¿Y las que aparecen a mediados de mes?. En otras ocasiones ocurre que no conocemos la fecha completa. Mientras esperamos averiguarla deberíamos poder poner los datos que tenemos. Me he encontrado ese problema en cuestiones de Historia o en tablas de registro de aeronaves donde la entrada en servicio, matriculación o destrucción de una aeronave no se conoce con precisión. En este caso una solución es separar día, mes y año en tres campos, asi podemos usar 00-03-09 para «primeros de marzo de 2009», «99-02″ para últimos de febrero o » – -1987″ para todo el año 1987. Esto tiene el inconveniente de tener que usar una función que combine los tres campos para producir una fecha, que la indexación por fechas debe hacerse a través de los tres campos y que hay que añadir un campo para establecer si la fecha es o no congruente, lo que complica el proceso de la información. Otra solución es usar las convenciones citadas pero en un campo de texto donde no tendremos ningún problema en anotar «00-00-2009» para «principio de 2009» aunque si queremos ordenar por este campo lo mejor es anotar una fecha como «20090430» para el treinta de abril de 2009 porque de esa forma aunque el tipo de campo sea una cadena de caracteres, la ordenación será correcta.
Por regla general estas son las dudas más comunes a la hora de diseñar Bases de Datos de uso personal y no existe una respuesta exacta sobre cual es el mejor criterio a seguir. Lo mejor es hacer una estimación sobre la necesidad de disponer de la información detallada y la posibilidad que existe de que en un futuro nuestras necesidades cambien y el esfuerzo que supondría cambiar la estructura de los datos.
El siguiente nivel de perfección seria poder relacionar de forma útil y congruente las diferentes bases de datos. Por ejemplo s mi contabilidad dice que tal día hice un gasto en libros de ahi tendría que poder pasar a la ficha del libro que compré y de esa al teléfono del librero o al documento en que usé una cita del libro. O a la foto que hice a la hora de la compra y a través de su geoetiqueta a la dirección de la librería donde lo compré.
Y naturalmente nivel máximo de perfección incluiría una interfaz no ya coloquial sino de conexión directa al cerebro que nos permitiría interrogar, obtener resultados o modificar los datos con la misma facilidad que si contásemos con una memoria perfecta.