duplicar info o hacer inner joins

[Blashak]

Buenas,

Queria saber si es mejor duplicar informacion que hacer inner joins.
Un ejemplo
si necesito saber el total de materiales eliminados genero un campo materiales_eliminados en la tabla materiales y por cada material que elimino lo sumo o hago un inner_join con la tabla materiales_eliminados que tiene varios campos y cuento los registros.

cual de las dos opciones es mejor.

[gnzsoloyo]

Duplicar información siempre es una mala idea.
En realidad, ni siquiera necesitas una tabla de "materiales eliminados", sino tener dos campos adicionales: fecha de eliminación y usuario eliminador. La idea es que si un material está activo, ambos campos son NULL; y si se eliminó, tienen datos.
En realidad un sólo campo podría ser suficiente, pero el segundo es buena idea para auditorías (siempre es bueno saber quién metió la pata).
El principio que hay por detrás es que cuando se ingresa un dato a una tabla base, o tabla primaria (aquellas de las que dependen todos los procesos inciales), esos registros jamás se borran. Cuando mucho se desactivan. Y no se borran porque siempre habrá información dependiente de ellos en alguna parte, información que no puede quedar huèrfana. Y como no puedes hacer depender una FK de dos tablas diferentes al mismo tiempo, entonces "pasar" los datos a otra tabla de "eliminados" no es la solución correcta.
¿Se entiende el dilema a nivel de diseño?
Únicamente hay "duplicidades" de datos en los Data Warehouse, y los Data Mart. Pero no en las bases de datos para producción (la de uso).
Toda duplicidad es riesgo de inconsistencia, y una inconsistencia dará resultados catastróficos en algún momento (no es opcional, tarde o temprano sucederá).

[Blashak]

gnzsoloyo,

pero la tabla material_eliminados la tengo que tener porque contiene muchos campos. ademas, ahora no recuerdo pero tambien me encuentro en el trabajo con muchas situaciones que no se que es mejor si duplicar un campo o hacer inner joins porque si estas hablando de tablas que tiene muchos registros igual en vez de tener que hacer tres inner joins para tener la info de un solo campo te conviene tener ese campo en la tabla principal.

Saludos

[gnzsoloyo]

pero la tabla material_eliminados la tengo que tener porque contiene muchos campos.

¿Muchos campos provenientes de qué?
Sin saber cómo es el diseño del sistema, no es fácil darte consejos.

me encuentro en el trabajo con muchas situaciones que no se que es mejor si duplicar un campo o hacer inner joins porque si estas hablando de tablas que tiene muchos registros igual en vez de tener que hacer tres inner joins para tener la info de un solo campo te conviene tener ese campo en la tabla principal.

Eso no es necesariamente cierto.
Que tengas muchos registros, sólo se puede decir si los registros son centenares de millones. Centenaress de miles no son problema, por lo que sin mas datos no estoy seguro de qué problemas te causan.
Además, como te dije, duplicar datos en otras tablas no es una buena idea porque aumenta el riesgo de inconsistencia, y en ciertos contextos, el proceso de verificación de consistencia se come todas las ventajas que puedes lograr duplicando esos datos. ¿Entonces qué ventajas tendría?
Por otro lado, el que tengas que hacer un triple INNER JOIN ni siquiera es un problema... Hay consultas en algunas bases que trabajo que tienen hasta 16 INNER JOINs juntos, y eso no significa ni lentitud, ni problemas, porque existe una excelente optimización de las mismas.
Antes de ponerse a duplicar datos, es conveniente ver si el problema de acceso a la información se puede resolver usando vistas, e incluso funciones.
Hay muchos recursos posibles, sin necesidad de terminar atentando contra la consistencia y la integridad de datos.

De todos modos, como ya mencioné, sin datos más concretos acerca del sistema y el diseño de la base, no hay mucho mas que pueda decirte.
Yo soy de la idea de de no duplicar datos innecesariamente, porque he visto y trabajo a cada rato con los problemas que causa ese tipo de cosas en la empresa donde estoy, producto de la idea de "facilitar" el acceso y reducir la cantidad de INNER JOINs existentes.
¿Cuál es el resultado?
Las aplicaciones colapsan en determinados momentos porque consultas a dos tablas que deberían tener datos compatibles no los tienen... porque no hay consistencia.
A la larga, lo único que tendrás serán problemas.

En cuanto a lo de no eliminar los datos de las tablas base, es un principio que aprendes dentro de las "buenas prácticas" de DBA. No lo inventé yo.

Duda: Esa tabla de eliminados, ¿la usas para guardar más datos además de una copia del registro de la tabla origen?