viernes, 7 de marzo de 2008

Historia de una tabla autoreferenciada

Corrian los tiempos en que diseñaba una Base de Datos para un sistemita. La idea era una tabla que almacenará un catálogo de servicios con una descripción, un precio, etc. Al principio, no representaba mucho reto... era relativamente fácil la creación y edición de esta para después realizar las altas, bajas, consultas y modificaciones.

Pero sucedió lo que a muchos desarrolladores les tiene que pasar algún día. Los requerimientos cambiarón... y una sola tabla no sería suficiente. Ahora era necesario catálogar esos mismos servicios, y tal vez lo primero que viene a la cabeza es crear una tabla mas con los catálogos y relacionarlos con la tabla de servicios.

Sin embargo, en el caso de este desarrollador que se había dormido en sus clases de Base de Datos en los temas de Joins, SelfJoins, RigthJoins, etc., era algo que le complicaba su trabajo..., tener que crear esa clase de consultas SQL me ponía en un aprieto.

Tenía que encontrar una manera de resolver el problema sin complicar el acceso a los datos, sobre todo pensando a futuro que las consultas SQL podrían tardarse mucho en ejecutarse debido a la enorme cantidad de datos que algún día manejaría.

Así que, al método de prueba y error, se modificó el diseño de la tabla agregando dos columnas mas:



La columna TIPO y TIPO_RELACION resolvía mi problema. La idea era que cuando se agregará un cátalogo, este tendría automáticamente en su campo TIPO las letras CT que lo identifican como catálogo y en el campo TIPO_RELACION la letra T (o cualquier otra, incluso sin letra) concatenandole el ID del registro, que mas adelante sería utilizado.



Agregado el catálogo, ahora era posible agregar un servicio que pertenecierá a ese catálogo, relacionado por el campo TIPO_RELACION. La imágen muestra el registro 13, donde se agregó un catálogo, con TIPO CT y TIPO_RELACION C13. Posteriormente, agregando mediante el sistema un servicio, este pertenece al catálogo anterior, colocando en su campo TIPO C13. De esta manera "apuntamos" el servicio a directamente con el catálogo que lo contendrá. Cabe mencionar que el campo TIPO_RELACION se quedo vació ya que este servicio no contendrá a nadie mas.



Fue así como conseguí, de pura casualidad una tabla autoreferenciada... o eso me lo dijo un cuate... e investigando me di cuenta que es algo muy útil, pero pocas veces utilizadas en las Bases de Datos. Analizando este método nos dimos cuenta que no solo se aplica en un solo nivel, si no que incluso se presta perfectamente para mas niveles de jerarquía, como por ejemplo, clasificar los catálogos, en otro catálogo, o incluso los servicios, podrían contener en su interior mas servicios y variantes... y a su vez estos. Un estilo de árbol jerarquíco cuya implementación es mas barata que utilizar un sin fín de tablas y relacionarlas todas entre ellas.

Al final, las tablas autoreferenciadas me han funcionando muy bien, sin ninguna clase de problemas hasta la fecha.

4 comentarios:

Anónimo dijo...

See Here or Here

Anónimo dijo...

HOLA MUÑECO SE VE QUE TE FASCINA LA PROGRAMACION, POR TODO LO QUE PONES HAS DE SER TODO UN MAESTRO DE MAESTROS A VER CUANDO ME DAS UNAS CLASES, PERO RECUERDA NO DIGAS TODO LO QUE SABES LO IMPORTANTE ES SABER TODO LO QUE DIGAS. POR CIERTO ME ENCANTAS ESTAS BIEN LINDO MAU.

SIGUE ECHANDOLE GANAS.

Dr Omm dijo...

Ah caray...jejeje... gracias por el consejo y el cumplido. En verdad el único deseo es compartir un poco de lo poco que se, con el fin de que a alguien le sirva, como ha servido a mi... por ke de eso se trata ser parte de internet, de compartir.
Por cierto que tienes toda la razon en eso de saber muy bien lo que uno dice...gracias

Julius dijo...

Minimo deja tu correo y tu nombre no?? Yo tambien programo, no tanto como el Dr Omm, pero tambien tengo lo mio, bueno espero que pongas tu correo y tu nombre, ya si se puede puedes poner tu direccion, telefono, celular, etc etc. Saludos :D