Dilema: Versión de Registros/Tuplas en la Base de Datos ¿Como?

[D-MO]

Hace mucho que no escribía por acá, y aunque lo visito frecuentemente, la verdad es que no tenía nada productivo que aportar, aunque ¿Será que ya tengo algo productivo que aportar?.

Bueno, al grano. Llegó el momento de poner un poco de orden donde trabajo, llevar un mejor control. Trabajo en el área de Soporte Técnico en una Institución del Estado y la verdad es que no puedo opinar mucho de los controles de TI pues los desconozco, no existen. Pero bueno, de nuevo me salí del tema...

Resulta que desde hace algunos días he estado con la inquietud de empezar con algunos controles de TI, y porqué no, desarrollar el sistema a medida basándome en mi experiencia en este puesto. Pero no quiero hacer las cosas porque si, ni tirarme al agua sin saber nadar. Quiero trabajar con reglas/procedimientos probados, que han tenido éxito, que miles de empresas usan a nivel mundial y que mejor que estudiar la norma ISO/IEC 20000, mas específico, desde la Biblioteca de Infraestructura de Tecnología de Información (ITIL, por sus siglas en inglés).

Obviamente, implementar todo lo que indica ITIL es una tarea enorme, casi imposible para una sola persona, ¿pero de que sirve la vida son los retos?... Para empezar, quiero iniciar por el principio ... la CMDB.

Acá pongo la imagen de mi diagrama de herencia de clases (aún no están marcadas la relaciones) donde podremos ver el nivel de detalle al que debemos llegar (según ITIL) para poder llevar un control completo.


Uploaded with ImageShack.us

En el diagrama faltan muchos objetos por modelar, y casi todos los modelos no tiene sus atributos asignados, sin embargo, ya podemos darnos una idea de la CMDB.

La CMDB es la parte central según ITIL. Yo en lo personal lo veo muy acertado. Pero la CMDB tiene una característica peculiar, debe mantener un histórico de los estados/cambios/sucesos vinculados a un equipo, así, si decimos que a la computadora X le incrementamos la memoria ram, pasó de ser X.n (n por en número de versión) a ser X.{n+1}... ¡¡¡Excelente!!!, aquí si hay control.

Mi frustación hasta este momento, ha iniciado en este punto. ¿De que manera debería de implementarse esta "pequeña" característica requerida según ITIL?. De momento se me ocurren dos posibilidades, pero ninguna de ellas me convence, las indico:

• Una tabla, registros duplicados

La primera posibilidad sería tener una llave primaria compuesta, formada por el ID del equipo y la versión del mismo, cada que cambia de versión duplicar el registro (para mantener el histórico), cambiar el estado del registro anterior y marcar como activo al registro nuevo. De entrada se ve bastante prometedor, hasta que nos topamos con el problema de como hacer para que, cada dispositivo esté vinculado a la versión actual pero también saber a que otras versiones del mismo u otro equipo ha pertenecido, pues, al pasar la computadora X de X.n a X.{n+1} solo podríamos hacer referencia de los dispositivos hacia una sola versión del equipo. ¡Ouch!

Dos tablas, Encabezado + Histórico

La segunda opción quizá sea un poco mas funcional, sin embargo, no termina de convencerme. Explico:

Tenemos dos tablas, una tabla Computadora y otra Histórico de Computadora. Entonces, desde la tabla de cada dispositivo hago referencia al ID del equipo y en la tabla Histórico de Computadora mantengo un registro por cada versión de la computadora con llave foránea hacia la tabla Computadora utilizando el ID.

De esta manera resolvemos el problema encontrado en la opción anterior, sin embargo, lo que no me parece es que debería de tener una tabla histórica por cada objeto modelado, imaginen:

• hard_disk
• hard_disk_revisions
• ram
• ram_revisions
• network_card
• network_card_revisions
• access_point
• access_point_revisions
• etc...

No me convence por "estética", la parte de desarrollo no me preocupa pues con cualquier ORM podría definir un modelo de tipo "Versionable" y la superclase se encargaría del trabajo sucio, lo que no me gusta es ver la BD con tanta tabla duplicada.

¿Ustedes que opinan?