Nog wat antwoorden op uw vragen:
1) Je bent zo goed als op schema voor iemand die voor het eerst een probleem als dit benadert. Ik denk dat de aanwijzingen van anderen over deze vraag tot dusverre het grotendeels dekken. Goed gedaan!
2 &3) De prestatiehit die u zult ondervinden, is grotendeels afhankelijk van het hebben en optimaliseren van de juiste indexen voor uw specifieke vragen / procedures en, belangrijker nog, het volume aan records. Tenzij je het hebt over meer dan een miljoen records in je hoofdtabellen, lijkt het erop dat je op weg bent naar een voldoende mainstream ontwerp dat prestaties geen probleem zullen zijn op redelijke hardware.
Dat gezegd hebbende, en dit heeft betrekking op uw vraag 3, vanaf het begin zou u zich waarschijnlijk niet al te veel zorgen moeten maken over de prestaties of overgevoeligheid voor normalisatie-orthodoxie hier. Dit is een rapportageserver die u aan het bouwen bent, geen op transacties gebaseerde applicatie-backend, die een heel ander profiel zou hebben met betrekking tot het belang van prestaties of normalisatie. Een database die een live aanmeldings- en planningstoepassing ondersteunt, moet rekening houden met query's die seconden duren om gegevens te retourneren. Niet alleen heeft een rapportserverfunctie meer tolerantie voor complexe en langdurige zoekopdrachten, maar de strategieën om de prestaties te verbeteren zijn heel anders.
In een op transacties gebaseerde toepassingsomgeving kunnen uw opties voor prestatieverbetering bijvoorbeeld bestaan uit het tot in de puntjes aanpassen van uw opgeslagen procedures en tabelstructuren, of het ontwikkelen van een cachingstrategie voor kleine hoeveelheden veelgevraagde gegevens. In een rapportageomgeving kunt u dit zeker doen, maar u kunt een nog grotere impact hebben op de prestaties door een snapshotmechanisme te introduceren waarbij een gepland proces wordt uitgevoerd en vooraf geconfigureerde rapporten opslaat en uw gebruikers toegang krijgen tot de snapshotgegevens zonder stress op uw db-laag op per aanvraag.
Dit alles is een langdradige tirade om te illustreren dat welke ontwerpprincipes en -trucs je gebruikt, kunnen verschillen, gezien de rol van de db die je aan het maken bent. Ik hoop dat het nuttig is.