Respuestas:
Debería ir tan lejos como debería, y no más. Por supuesto. ~ El problema puede ser que esto es un poco un arte, y es por eso que esto no es una ciencia pura.
Nuestro producto principal es un sistema de análisis e informes, por lo que, en ese sentido, tenemos bastantes registros detallados. Inicialmente lo diseñamos con muchas combinaciones en una ID común para algunos de los registros secundarios, pero descubrimos que si desnormalizamos un par de campos podríamos cortar MUCHAS combinaciones y eliminar muchos dolores de cabeza de rendimiento.
Pero solo sabíamos que porque 1) creamos un diseño "normalizado", 2) comenzamos a usarlo, 3) perfilamos el rendimiento real después de cientos de millones de filas en docenas de tablas.
La historia final es que hasta que hicimos un perfil no podíamos saber con certeza qué iba a funcionar para nosotros. Nos gustó la idea de normalizar para poder actualizar más fácilmente, pero al final el rendimiento fue el factor decisivo. Ese es mi consejo para usted: Perfil, perfil, perfil.
in ('forgiven','pardoned');): p
La normalización es un objetivo solo cuando admite su modelo de datos lo suficientemente bien como para garantizarlo. Está destinado a ser una guía para permitir el crecimiento, la gestión y la mantenibilidad. Recuerde que el libro sobre normalización, ni su escritor van a construir o mantener su base de datos o su aplicación.
Una buena lectura sobre el tema de "demasiada normalización" está aquí.
Y sí, puede haber impactos en el rendimiento por demasiada normalización. Esto sería en un recorrido de tabla más profundo para recoger cosas como tablas de indicadores de estado cuando se han sacado a una tabla separada. Algunos dirán que esto generalmente se niega en la velocidad de actualización (cambiando el texto de estado de "Bueno" a "BUENO" o algo similar) o en mantenimiento.
Recomiendo leer el siguiente apéndice que se encuentra en algunos de los libros más recientes de Chris Date :
Dos hurras por la normalización
La normalización está lejos de ser una panacea, como podemos ver fácilmente al considerar cuáles son sus objetivos y qué tan bien se compara con ellos ...
Debo dejar en claro que no quiero que mis comentarios en esta sección sean vistos como ningún tipo de ataque. Creo firmemente que cualquier cosa menos que un diseño totalmente normalizado está fuertemente contraindicado ...
Creo que es igualmente importante observar las denormalizaciones agregadas explícitas, ya sea valores agregados agregados o algunos campos de una tabla maestra copiados a una copia detallada.
El argumento es principalmente un argumento de rendimiento.
Si lo hace, que los campos se actualicen mediante disparadores y que la base de datos debe mantenerlos consistentes.
Estoy totalmente de acuerdo con @jcolebrand. Cuando diseñe el modelo para su aplicación, debe normalizar todo lo que pueda. Pero luego debe perfilar las consultas creadas sobre su modelo, especialmente las ejecutadas con frecuencia.
Mi propia experiencia: los atributos que tomaron dos uniones para alcanzar (lo que significa que se unieron tres tablas) serán en su mayoría un gran rendimiento. Y para empeorar las cosas, se utiliza en transacciones en línea. Desnormalizo el atributo, por lo que solo necesito una unión y le pedí al programador que ajuste su aplicación para la consulta y actualice el atributo. Ahora funciona mucho mejor ...
En otras palabras, debe equilibrar la normalización con el rendimiento.