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

[luisgutierrezb]

yo creo que las multiples tablas si serian la opcion porque por ejemplo en disco duro tal vez debas especificar que tipo es, ide, sata, SSD aparte de la capacidad y que tal si adquiren un disco hibrido sata-ssd y que tal si despues salen los discos duros enfriados por agua (es un decir) entonces con una tabla por componente creo yo que aunque es mas trabajo, es mas facil el mantenimiento, o solo que se uniformaran las caracteristicas de todos los componentes donde tipo sea DDR3 para la memoria y Sata para un disco duro y blue ray para una unidad optica, etc

[D-MO]

Saludos Luis, lo que dices es justamente la razón por la que cada clase representa un objeto real, osea, se está modelando desde el punto mas bajo. En diagrama ER no he detallado todos los atributos de cada objeto, solo las diseñé para darme una idea y evaluar de mejor manera la situación. La verdad es que quizá termine diseñando un híbrido entre ambos modelos, es a lo que le he estado dando vueltas.

Otro punto muy importante, que no he especificado. Quizá alguien esté pensando que si estamos duplicando los registros cada que se hace una modificación, la BD crecerá de manera exponencial. La verdad que sí, eso está contemplado. Lo que estoy pensando es que la aplicación en producción debería ser "purgada" cada cierto tiempo, dependiendo del volumen de información que almacene. Así podríamos decir que cada 15 días se saca una copia de los registros y pasan a una segunda base de datos, la Base Histórica, el Data Warehouse, y será desde acá donde se generarán los reportes, así no sacrificamos el rendimiento de la aplicación en producción cada que se necesite un reporte muy detallado.

Esta es mi loca idea hasta el momento, a ver en que termina.

Saludos.