Por Isaúl Esteva López
Publicado en mayo 2011
Situación actual
La administración de catálogos es un tema básico dentro de casi cualquier aplicación web o standalone, y su administración puede volverse complicada o tediosa si no tenemos un buen análisis o un diseño adecuado para resolver este caso de uso.
Vamos a comenzar analizando una situación real.
Supongamos que tenemos una aplicación en la cual tenemos que realizar las altas, bajas, cambios y consultas de más de un catálogo.
La primera aproximación que tenemos cuando estamos realizando nuestro modelo de datos es comenzar a crear tantas tablas como catálogos necesitamos, mismas que se convertirán de manera natural en tantas clases que representen a dichas tablas dentro de nuestra aplicación.
Podemos identificar dos tipos de catálogos:
Los catálogos que cuentan con una serie de datos que los identifica de manera única, como en el caso del catalogo de Países.
Y los catálogos que tienen referencia a otros catálogos, como en el caso de Estados.
¿Cuál es el problema?
Si seguimos la estrategia de crear tantas tablas como catálogos necesitamos, vamos a estar creando (dependiendo de nuestro negocio a resolver) una gran cantidad de tablas dentro de la base de datos, mismas que pueden llegar a almacenar un número muy pequeño de registros (30 registros aproximadamente).
Otra consecuencia de esta solución es la gran cantidad de clases java que vamos a necesitar para poder realizar las operaciones de alta, baja, cambio y consultas de dichos catálogos.
Una consecuencia más de esta estrategia ocurre cuando estamos trabajando en equipo y repartimos e desarrollo de los catálogos entre los miembros del equipo, pues cada programador llega a implementar la solución como mejor le conviene.
Otra consecuencia es la diversidad de puntos de acceso que tenemos hacia los catálogos, ya que estos se crean según vamos avanzando en el desarrollo.
Y quizá la consecuencia que se nos escapa a menudo con esta estrategia es la seguridad, es importante entender que mientras mas menús y sub menús tengamos en nuestra aplicación, la administración de la seguridad se vuelve más compleja.
Estos son sólo algunos problemas que surgen al adoptar este tipo de estrategia.
¿Cuál es la mejor alternativa de solución?
En realidad existen diferentes alternativas de solución a este tema, pero una de las mejores alternativas que he encontrado e implementado es la siguiente:
Tener dos tablas, una para almacenar la información de los tipos de catálogos y otra para almacenar los registros de nuestros catálogos, la idea consiste en tener sólo una tabla donde almacenaremos los registros de todos los catálogos de nuestro sistema, y una tabla que identifique de qué tipo de catálogo es el registro guardado.
Solución
Lo primero que haremos es crear una tabla que almacenará los tipos de catálogos, su función será almacenar todos los tipos de catálogos que podemos tener dentro de nuestra aplicación.
Descripción de campos:
IDTIPO: Este campo será el identificador de los tipos de catálogos que vamos a crear.
DESCRIPCION: Este campo guarda la descripción o el nombre del tipo de catálogo.
Después crearemos la tabla de catálogos, su función será almacenar todos los registros de todos los catálogos con los que contemos.
Descripción de campos:
IDCATALOGO: Este campo será el identificador de los registros almacenados en esta tabla.
IDTIPOCATALOGO: Este campo será el identificador del tipo de catálogos al que pertenece el registro.
IDPADRE: Este campo hará la referencia entre en registro insertado y su padre, para el caso de un registro de tipo ESTADO, en este campo irá el ID del registro de tipo PAIS al que pertenece el estado.
DESCRIPCION: Este campo guarda la descripción o el nombre del catálogo.
De modo tal que nuestro esquema quedaría de la siguiente manea.
Esta alternativa de solución es aplicable y muy eficiente cuando la cantidad de registros que tenemos en cada catálogo no excede los 50 registros.
Hay ocasiones en que la cantidad de información a almacenar en un catálogo es lo suficientemente grande que es necesario tener tantas tablas como catálogos de ese tipo necesitemos.
Publicado por Isaúl Esteva López (isaul.esteva@oracle.com), actualmente se desempeña como Enterprise Accounts en Oracle México.