OT: mejores practicas

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).

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;
}

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

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)

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.

pero para hacer esto y asegurar integridad referencial tendria que tener
otra referencia de tablaD a tablaA.y aqui es donde dice mi amigo que eso lo
hace lento. y dificil de mantener despues.

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

--
________________________________________
Lo bueno de vivir un dia mas
es saber que nos queda un dia menos de vida