Re: OT: mejores practicas

Miguel Beltran R. escribió:

> El 20 de marzo de 2009 9:31, Jaime Casanova
> <jcasanov(at)systemguards(dot)com(dot)ec>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")