Re: OT: mejores practicas

2009/3/19 Miguel Beltran R. <yourpadre(at)gmail(dot)com>:
> Platicando con un amigo sobre como es mejor diseñar una base de datos
> tenemos un punto de desacuerdo.
>
> Yo digo que siguiendo la normalización en ocaciones puede ser un problema
> creo (ó es un mal diseño mio tal vez).
>

esto no parece muy normalizado que digamos...

> Por ejemplo siguiendo la normalización (la estructura es solo para dar una
> idea):
> tablaA {
> id  serial;
> proyectoA  integer PRIMARY KEY;
> proyectoA_nombre  text;
> anio  integer;
> }
>

para que el "id serial"? todas las tablas tienen uno y me parece que
no sirve a ningun proposito util...

> tablaB {
> id serial;
> proyectoA integer reference tablaA (proyectoA)
> proyectoB integer PRIMARY KEY
> fecha  date;
> fondo  varchar(10);
> cuenta varchar(10);
> }
>

si tabla B depende directamente de tabla entonces proyectoA deberia
formar parte del PK, por ejemplo si tabla B almacena algun tipo de
detalle (como en el caso de la factura y el detalle de la factura)
pero sin saber que tipo de informacion se va a almacenar solo son
conjeturas

> tablaC {
> id serial;
> anio integer; --es el mismo que en tablaA
> proyetoC integer;  --es un consecutivo que empieza
>                            --en 1 cada año, no se debe repetir
>                            --por eso se combina con anio.
> proyectoB integer REFERENCE tablaB (proyectoB);
> }PRIMARY KEY (anio, proyectoC)
>

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

> tablaD {
> id serial;
> tablaC_id integer REFERENCE tablaC (id)
> tipo char(1);
> folio integer;
> }PRIMARY KEY (tipo, folio)
>
>
> El problema que le digo a mi amigo, es que si necesito unos datos de tablaD
> filtrada por anio y proyectoA tengo que hacer muchos INNER JOIN -((tablaA
> inner JOIN tablaB) inner join tablaC) inner join tablaD-, y yo se que me van
> a pedir muchos reportes con esas caracteristicas. Y como estas los costos de
> almacenaje no representa mucho el gasto espacio de disco duro y si mas
> rapides si guardo esos 2 campos (ejercicio y proyectoA) en la tablaD.
>

haz los cambios que te digo y me cuentas...

> ¿quién tiene rázon? ¿cómo sería lo mas rapido/mejor.?
>

lo mas rapido no siempre es lo mejor y viceversa... mejor es hacerlo
primero bien y luego preocuparse de que responda rapido... despues de
todo, "la optimizacion prematura es la raiz de todos los males" (no
recuerdo quien lo dijo)...

--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157