Mmm yo crearía dos tablas. Una que sea una especie de diccionario de propiedades o y otra que vincule a la anteriormente mencionada con la tabla tuya de objetos y además un valor. Por ejemplo:
Objeto ======= Obj_codigo (PK) Obj_propiedad(FK a propiedad prp_codigo) Propiedad ========= Prp_codigo(PK Prp_dicionario(FK apunta a diccionario dic_codigo) Prp_valor Diccionario =========== Dic_codigo(PK) Dic_nombre De esta forma vas poniendo características, todas las que quieras, y cada objeto es independiente de los otros porque en realidad esta vinculado en las tablas. Espero haber sido claro y de ayuda. Saludos Germán C. Basisty Estudio Informático Patagónico Consultor - Tecnología Informática [EMAIL PROTECTED] http://www.eipsistemas.ath.cx -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Pablo Lillia Enviado el: lunes, 11 de agosto de 2008 07:57 p.m. Para: Lista de temas generales del LUGAr y de Linux Asunto: Re: [LUGAr-gral] OT: pregunta de diseño de DB 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] No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.6.1/1605 - Release Date: 11/08/2008 04:59 p.m. -- 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]
