FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Eso es muy simple.
Hace unos años (en 1999!!) me toco hacer el rediseño de la entrada de notas u hoja de calificaciones. Si miran un reporte de esos, veran que es una columna con nombres y una columna por cada periodo de notas (que pueden ser hasta 12....) Y si, la idea original era un miercolero de selects y funciones en fox. Luego se me ocurrio que cual era el lio de simplemente clavar las columnas directamente en la estructura? Asi que queda masomenos: idAlumno, idMateria, obs1...obs2, otros campos Y !zaz! se simplifico el codigo que da miedo, y los reportes salieron mas facilitos! A veces, hay que perderle el miedo a desnormalizar. Desde entonces aprendi que la funcion de una estructura de BD no es la normalizacion, sino la adaptacion mas natural para la aplicacion (y generalmente es la forma de entrada de datos mas comun).
__________________
El malabarista. |
#2
|
||||
|
||||
¿Es decir que tu solución al problema sería la siguiente?:
tabla contratos Cita:
Realmente desnormalizas, pero no te digo yo que me dan ganas de hacerlo porque te ahorras dolores de cabeza |
#3
|
||||
|
||||
Piensa a la larga, no sea que los dolores de cabeza que te ahorres ahora, se conviertan en errores más grandes dentro de un tiempo...
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#4
|
||||
|
||||
ja ja ja no si por eso lo digo Neftali, ya hace varios post he decidido implementar la idea de coso (maestro->detalle + campo memo informativo en maestro con los datos del detalle para consultas) , pero en un principio me pense plantar los 4 campos de partes y a tomar vientos
|
#5
|
||||
|
||||
Cita:
Sigo pensando que esa estructura no es correcta. No es buena para almacenar información (puesto que no es fija -numero fijo de campos-), no es buena para mostrar información (por lo que ya se ha comentado antes) y no es buena para recuperar información (puesto que no está normalizada); Esto último implica que lo que apriori parace más sencillo luego se vuelva más complicado y lento. Por ejemplo, buscar o agrupar los contratos que tienen partes con una empresa; Calcular el importe facturado a una empresa (a partir de los partes a esa empresa) o los contratos que tienen algun parte de una determinada Clase. 1º) para esto vas a tener que empezar a hacer: ... OR PARTE1 ... OR PARTE2 ...OR PARTE3... 2º) Si mañana se necesitan 5 partes, en lugar de 4, además de cambiar las inteficies, vas a tener que cambiar las consultas. No digo con esto que la normalización se tenga que llevar a "raja-tabla", yo mismo en casos muy puntuales he "desnormalizado", pero creo que este caso no lo justifica; Es mi opinión, pero creo que esa solución es una pésima opción.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. Última edición por Neftali [Germán.Estévez] fecha: 22-09-2008 a las 16:39:59. |
#6
|
||||
|
||||
Yo estoy de acuerdo con Neftalí. Sin saber más detalles acerca del sistema en particular, no es posible determinar si una denormalización es conveniente o no. De que lo hacemos lo hacemos. Yo tengo una tabla de personas con dos campos para teléfonos. Estrictamente hablando tendría que que separarlos en una tabla aparte pero no hay ningún viso de que en algún futuro sea necesario, así que, no hay necesidad.
Pero si existe esa posibilidad -y hablando de empresas que forman parte de un contrato, da la impresión de que así será- no puede evitarse la mormalización. Y, como menciona el mismo Neftalí, muchos reportes se complicarán terriblemente por no haber normalizado. Vamos, que la normalización no es un concepto que alguien se fumó por ahí. // Saludos |
#7
|
||||
|
||||
Pues yo aun sabiendo los detalles de la aplicación te hacen dudar ...muchas veces hay que ser vidente El usuario me jura y perjura que en un contrato solo abrá 3 partes a lo sumo 4. Pero claro yo no me fio y por eso normalizo y saco la tabla partes fuera de la tabla contratos.
Luego tengo la tabla Escrituras de Poder* y me pasa lo mismo, el usuario me dice que como máximo en una escritura puede haber 8 apoderados, pero como antes yo no me fio y normalizo sacando la tabla apoderados fuera de la tabla escrituras. Es dificil ser vidente y por eso me cubro en salud normalizando, lo único que a priori y para informes quizás es más facil desnormalizar, porque imaginate que tu normalizas tu tabla de personas y sacas la tabla teléfonos, y ahora te piden el informe -> Persona Telefono1 telefono2 telefonoX.... MasDatos .... Yo de momento voy a normalizar e incluire un campo en el maestro con todos sus detalles . Haré una demo, como bien me dijistes y trataré de convencerles (*) Papeles que otorgan poder a cierta persona/s , por ejemplo un empresario otorga el poder de firmar facturas a su empleado pepito y juanito. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
¿Mision imposible? | Alvarobc | Conexión con bases de datos | 8 | 26-04-2007 05:40:34 |
Es imposible un lector de DVD???? | gandalf_27 | Varios | 2 | 15-06-2006 16:07:40 |
Es Esto imposible? | jam888 | Varios | 1 | 28-04-2005 01:02:35 |
imposible con interbase | jomaho | Firebird e Interbase | 1 | 10-05-2003 11:44:14 |
|