Algunas respuestas más a sus preguntas:
1) Estás más o menos en el objetivo para alguien que aborda un problema como este por primera vez. Creo que los consejos de otros sobre esta pregunta hasta ahora lo cubren bastante. ¡Buen trabajo!
2 y 3) El impacto en el rendimiento que obtendrá dependerá en gran medida de tener y optimizar los índices correctos para sus consultas/procedimientos particulares y, lo que es más importante, el volumen de registros. A menos que esté hablando de más de un millón de registros en sus tablas principales, parece estar en camino de tener un diseño lo suficientemente convencional como para que el rendimiento no sea un problema en un hardware razonable.
Dicho esto, y esto se relaciona con su pregunta 3, con el comienzo que tiene, probablemente no debería preocuparse demasiado por el rendimiento o la hipersensibilidad a la ortodoxia de normalización aquí. Este es un servidor de informes que está creando, no un back-end de aplicación basado en transacciones, que tendría un perfil muy diferente con respecto a la importancia del rendimiento o la normalización. Una base de datos que respalda una aplicación de registro y programación en vivo debe tener en cuenta las consultas que tardan segundos en devolver datos. Una función de servidor de informes no solo tiene más tolerancia para consultas complejas y largas, sino que las estrategias para mejorar el rendimiento son muy diferentes.
Por ejemplo, en un entorno de aplicación basado en transacciones, sus opciones de mejora del rendimiento pueden incluir la refactorización de sus procedimientos almacenados y estructuras de tablas al enésimo grado, o el desarrollo de una estrategia de almacenamiento en caché para pequeñas cantidades de datos comúnmente solicitados. En un entorno de informes, sin duda puede hacer esto, pero puede tener un impacto aún mayor en el rendimiento mediante la introducción de un mecanismo de instantánea donde se ejecuta un proceso programado y almacena informes preconfigurados y sus usuarios acceden a los datos de la instantánea sin estrés en su nivel de base de datos. por solicitud.
Todo esto es una perorata prolija para ilustrar que los principios de diseño y los trucos que emplee pueden diferir según la función de la base de datos que esté creando. Espero que sea útil.
