El 11/08/2008 17:59, Sebastian Bassi escribió: > Estoy atorado con un diseño de DB y se que aca hay mucha gente con > experiencia en el tema: > > Supongamos que tengo objetos que son los sujetos de mi base. Esos > sujetos (lineas) tienen sus caracteristicas (columnas o campos). Hasta > ahi todo bien. Pero cada tanto aparece, o sea, tengo que ingresar, > otra VERSION de un objeto existente (con sus caracteristicas). > Ejemplo, tengo: > > ObjetoA caracteristica1 caracteristica2 caracteristica3 > ObjetoB caracteristica1 caracteristica2 caracteristica3 > ObjetoC caracteristica1 caracteristica2 caracteristica3 > > Pero por ahi quiero meter el "ObjetoA-v2.0" (por poner un nombre). > ¿Como hago el diseño en este caso?. Tengan en cuenta que: > No hay limite en cantidad de versiones que puedo meter de A. > El usuario norrmalmente solo quiere "ObjetoA" y recibir los datos de > la ultima version del ObjetoA (no le interesa la "historia" de A). > Hace falta almacenar los estados previos del Objeto en cuestion por > motivos historicos fundamentalmente, al usuario final siempre le > importa el estado actual, pero cada tanto a alguno si le interesa > hacer una comparacion o mirar la evolucion del objeto. > Mi idea es poner un campo llamado "version", no se que se estila en estos > casos. > Bueno, espero que se entienda.
Haría eso mismo. Agregaría un dato "estado" o "activo". El registro activo, es la versión actual, y es una facilidad para excluir las versiones viejas. Además, tendría un timestamp, como alguna otra información (quién hizo el cambio) de loging al actualizar el registro. El timestamp es importante, no solo para conocer exactamente cuándo fue realizado el cambio, sino porque así es sencillo sacar de linea o mover a otra tabla las versiones viejas pasado X tiempo, si llegara a ser necesario. Con el campo version, un numérico autoincremental (o una secuencia de oracle por ej), se puede ordenar y obtener la historia (el timestamp suele ser suficiente, aunque prefiero tener también una version numérica, y va en gusto. El motivo para desconfiar el timestamp, es por si alguien juega con las fechas del equipo o sucede algo raro... con el timestamp eso no puede pasar y tengo un dato adicional interesante). Otra forma de hacerlo, es dejar solo el registro activo en la tabla, y guardar el histórico (las versiones previas) en otra. La ventaja de esto, al desdoblar en 2, es que según los volúmenes, crecimientos, etc., puede ser más fácil de manejar y "tunear". En este caso no tenés el dato "activo" (o está en una tabla "activo" o en "históricos"), pero el resto es igual (la columna versión, solo sería necesario en el histórico). Si se hacen muchas consultas que impliquen un full-scan de la tabla, es mejor tener una fracción (solo lo activo y necesario) de los registros. Slds.- Pablo -- Para desuscribirte tenés que visitar la página https://listas.linux.org.ar/mailman/listinfo/lugar-gral/ /* Publica y encontra trabajo relacionado con softlibre en http://www.usla.org.ar/modules/jobs/ */ Si tenés algún inconveniente o consulta escribí a mailto:[EMAIL PROTECTED]
