Miguel Beltran R. escribió: > El 20 de marzo de 2009 9:31, Jaime Casanova > <[email protected]>escribió:
> > para que el "id serial"? todas las tablas tienen uno y me parece que > > no sirve a ningun proposito util... > > Su mayor proposito es como punto de referencia de saber en que momento se > inserto el dato, para detectar posibles errores de captura. como meter el > proyectoA 99 y si despues reviso darme cuenta que lo metieron despues del > 65. y antes del 70. (no siempre nos tocan proyectos consecutivos 11,12,13) Eso no tiene mucho sentido IMO. Si quieres saber "cuando" se creó y modificó, agrega una fecha que sea la de creación y última modificación (esta última manejada con un trigger). Si necesitas más detalle que eso, quizas puedas agregar un log (cf. pgfoundry -> tablelog). > > si el anio es el mismo que en tabla A no deberia estar aqui, mas bien > > aqui deberia estar el codigo del registro de tablaA lo que me hace que > > pensar que mi suposicion de que proyectoA deberia formar parte del PK > > de tablaB es correcta > > Es el mismo, pero esta el anio para no tener que buscar el dato en la > tablaA. Es mala idea. Te recomiendo quitarlo, y una vez que la aplicación esté más avanzada, medir qué optimizaciones realmente necesitas. Lo más probable es que la desnormalización que te llegue a hacer falta (si es que alguna) sea totalmente distinto de lo que te imaginas al principio. > Una ultima duda con la rapidez, igual y por eso estoy mal con mis diseños. > Si hago una vista de tablaC que jale el dato de tablaA para tomar el anio, > cuanta carga se para la base. claro que usario indices. Diseña normalizado. Una vez que esté listo, desnormalizas sólo allí donde sea realmente necesario. De lo contrario es mucho más difícil mantener todo. -- Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC Officer Krupke, what are we to do? Gee, officer Krupke, Krup you! (West Side Story, "Gee, Officer Krupke") -- TIP 8: explain analyze es tu amigo
