Altre risposte alle tue domande:
1) Sei praticamente sul bersaglio per qualcuno che si avvicina a un problema come questo per la prima volta. Penso che i suggerimenti di altri su questa domanda finora lo coprano praticamente. Buon lavoro!
2 e 3) Il successo delle prestazioni che subirai dipenderà in gran parte dall'avere e ottimizzare gli indici giusti per le tue particolari query/procedure e, soprattutto, il volume dei record. A meno che tu non stia parlando di oltre un milione di record nelle tue tabelle principali, sembra che tu sia sulla buona strada per avere un design sufficientemente mainstream che le prestazioni non saranno un problema su hardware ragionevole.
Detto questo, e questo si riferisce alla tua domanda 3, con l'inizio che probabilmente non dovresti essere eccessivamente preoccupato per le prestazioni o l'ipersensibilità all'ortodossia della normalizzazione qui. Questo è un server di report che stai creando, non un back-end di applicazioni basato su transazioni, che avrebbe un profilo molto diverso rispetto all'importanza delle prestazioni o della normalizzazione. Un database che supporta un'applicazione di registrazione e pianificazione in tempo reale deve essere consapevole delle query che richiedono pochi secondi per restituire i dati. Non solo una funzione del server di report offre una maggiore tolleranza per query lunghe e complesse, ma le strategie per migliorare le prestazioni sono molto diverse.
Ad esempio, in un ambiente applicativo basato su transazione, le opzioni di miglioramento delle prestazioni potrebbero includere il refactoring delle procedure archiviate e delle strutture delle tabelle all'ennesima potenza o lo sviluppo di una strategia di memorizzazione nella cache per piccole quantità di dati comunemente richiesti. In un ambiente di reporting puoi certamente farlo, ma puoi avere un impatto ancora maggiore sulle prestazioni introducendo un meccanismo di snapshot in cui un processo pianificato viene eseguito e archivia i report preconfigurati e i tuoi utenti accedono ai dati dello snapshot senza stress sul tuo livello db su a per richiesta.
Tutto questo è uno sproloquio prolisso per illustrare che i principi di progettazione e i trucchi che impieghi possono differire dato il ruolo del db che stai creando. Spero di esserti stato utile.
