Nogle flere svar på dine spørgsmål:
1) Du er stort set på mål for en, der nærmer sig et problem som dette for første gang. Jeg tror, at pointerne fra andre om dette spørgsmål indtil videre dækker det stort set. Godt arbejde!
2 &3) Det præstationshit, du vil få, vil i høj grad være afhængig af at have og optimere de rigtige indekser til dine specifikke forespørgsler/procedurer og endnu vigtigere mængden af poster. Medmindre du taler om langt over en million poster i dine hovedtabeller, ser du ud til at være på vej til at have et tilstrækkeligt almindeligt design til, at ydeevnen ikke vil være et problem på rimelig hardware.
Når det er sagt, og dette relaterer til dit spørgsmål 3, med den start du har, skal du nok ikke være særlig bekymret for ydeevne eller overfølsomhed over for normalisering ortodoksi her. Dette er en rapporteringsserver, du bygger, ikke en transaktionsbaseret applikations-backend, som ville have en meget anderledes profil med hensyn til vigtigheden af ydeevne eller normalisering. En database, der understøtter en live tilmeldings- og planlægningsapplikation, skal være opmærksom på forespørgsler, der tager sekunder at returnere data. Ikke alene har en rapportserverfunktion mere tolerance over for komplekse og langvarige forespørgsler, men strategierne til at forbedre ydeevnen er meget forskellige.
For eksempel kan dine muligheder for forbedring af ydeevnen i et transaktionsbaseret applikationsmiljø omfatte refaktorering af dine lagrede procedurer og tabelstrukturer til n'te grad eller udvikling af en cachingstrategi for små mængder almindeligt anmodede data. I et rapporteringsmiljø kan du helt sikkert gøre dette, men du kan have en endnu større indvirkning på ydeevnen ved at introducere en snapshot-mekanisme, hvor en planlagt proces kører og gemmer forudkonfigurerede rapporter, og dine brugere får adgang til snapshot-dataene uden at stresse dit db-niveau på pr. anmodning.
Alt dette er en langhåret skænderi for at illustrere, at hvilke designprincipper og tricks, du anvender, kan være forskellige i betragtning af den rolle, som den db, du opretter, spiller. Jeg håber, det er nyttigt.