Sobre las etiquetas en internet y la normalización de las bases de datos

Una de las novedades que ha incorporado lo que llaman "Web 2.0" es la posibilidad de poner etiquetas a todos los contenidos que se van subiendo a Internet. En los vídeos de YouTube, las fotos de Flickr o los enlaces de del.icio.us se hacen casi imprescindibles. Los blogs no iban a ser menos y también traen esta funcionalidad. Este artículo está marcado con las etiquetas "informática" y "programación" dentro del conjunto de categorías de Inforserranía.

Antes de que se extendiera esta técnica, lo normal era que en general un artículo dentro de una base de datos estuviera asociado a una y sólo una categoría. Un campo clave externo en cada registro apuntaba a otra tabla con todas las categorías. Simple y muy organizado. Pero con el grave inconveniente de que a veces era difícil encontrar la mejor categoría. ¿Cual es más adecuada para esto, informática o programación?. Habría que elegir.

Con las etiquetas este problema se ha solucionado porque cada artículo puede llevar ninguna, una, o todas las que se quieran. Podemos describir con un nivel de detalle muy alto el contenido de la información para facilitar su búsqueda y clasificación. La web semántica y los sistemas de inteligencia artificial se encargarán de asignar las etiquetas automáticamente en el futuro. Por ahora hay que hacerlo a mano, pero esto ya es otra historia.

El problema que tenemos a la hora de diseñar la estructura de una base de datos con etiquetas es simple. En teoría una relación m:m de muchos a muchos entre la tabla de artículos y la tabla de categorías o etiquetas. Hace falta una tabla adicional intermedia que almacene información sobre cuales artículos tienen asiguadas cuales etiquetas. Y por supuesto nuestro programa se tendrá que encargar del mantenimiento de las tres tablas, de su integridad, y de tareas como que no queden etiquetas desiertas, indices, cachés, etc. La ejecución de las partes más pesadas se haría solo en los momentos de las actualizaciones. Las visitas de los usuarios se despacharían con sencillas consultas.

Esta es la teoría.

Pero en la práctica no nos metemos en tantos relíos de programación para una aplicación de pequeño y no tan pequeño tamaño. Tomamos el camino más corto y ponemos en cada registro de la tabla de artículos un campo de texto largo llamado "Etiquetas" y ahí cabe todo. Creamos una regla para indicar si las etiquetas van separadas por comas, espacios, etc. pero en definitiva se almacenan ahí todas juntas y repetidas en los distintos registros. Nos quitamos de enmedio las otras dos tablas y todas sus operaciones de mantenimiento en el momento de la actualización. Ahora montamos la aplicación de cara al usuario a base de consultas SQL y las funciones de manejo de cadenas de caracteres que traen los lenguajes de programación. Listamos todas las etiquetas de la tabla, las separamos y las metemos en un array, quitamos las duplicadas, las clasificamos por número de ocurrencias, y hasta dibujamos en tiempo real nubes de etiquetas o folksonomías con distintos tamaños de letra. Todo esto se hace cada vez que el usuario entra en una página. Muy rápido y simple de programar y de mantener, pero le estamos pidiendo al servidor que haga el pino con las orejas. Nuestros programas en una capa superior no están tan optimizados como el conjunto de instrucciones SQL que debieran actuar sobre las tres tablas y las relaciones que teníamos que haber creado y nos hemos ahorrado.

Está fallando la teoría de normalización de las tablas de las bases de datos. Para que una tabla cumpla las condiciones de lo que se llama "Primera Forma Normal" no podemos utilizar un campo como cajón de sastre para meter ahí todas las etiquetas juntas. En cada campo por definición sólo tendría que ir un valor. Es lo que llaman "atomicidad", que los valores almacenados no se puedan dividir en partes. Las consultas se hacen más complicadas y tenemos que recurrir a las ya citadas funciones de manipulación de cadenas para clasificarlo todo.

Pero si nos ponemos en este plan de super-optimización y anti-desnormalización, a lo mejor habría que plantearse el escribir los programas directamente en ensamblador y no usar los modernos entornos con iconos y colorines que meten tantas capas intermedias de interpretación en la ejecución de los programas. A fin de cuentas nuestra violación de la primera forma normal en la base de datos y el tratamiento intensivo de cadenas de caracteres sólo es una capa más. Haciéndolo con un mínimo de cuidado parece que va funcionando bien en los actuales ordenadores.

Los buenos analistas tendrán que decidir a la vista del uso que se vaya a dar a la aplicación cual solución es la mejor.


Temas relacionados
- ¿Es el Optimus Keyboard un periférico de salida?