Einige weitere Antworten auf Ihre Fragen:
1) Sie sind ziemlich genau richtig für jemanden, der sich einem Problem wie diesem zum ersten Mal nähert. Ich denke, die Hinweise von anderen zu dieser Frage decken sie bisher ziemlich gut ab. Gute Arbeit!
2 &3) Der Leistungseinbruch, den Sie erleiden werden, hängt weitgehend davon ab, ob Sie die richtigen Indizes für Ihre speziellen Abfragen / Verfahren haben und optimieren, und was noch wichtiger ist, das Volumen der Datensätze. Wenn Sie nicht von weit über einer Million Datensätzen in Ihren Haupttabellen sprechen, scheinen Sie auf dem richtigen Weg zu sein, ein Design zu haben, das ausreichend Mainstream ist, sodass die Leistung bei angemessener Hardware kein Problem darstellt.
Das heißt, und das bezieht sich auf Ihre Frage 3, mit dem Start, den Sie haben, sollten Sie sich wahrscheinlich nicht wirklich Sorgen um die Leistung oder die Überempfindlichkeit gegenüber der Normalisierungsorthodoxie hier machen. Dies ist ein Berichtsserver, den Sie erstellen, kein transaktionsbasiertes Anwendungs-Backend, das ein ganz anderes Profil in Bezug auf die Bedeutung von Leistung oder Normalisierung hätte. Eine Datenbank, die eine Live-Registrierungs- und Planungsanwendung unterstützt, muss auf Abfragen achten, die Sekunden dauern, um Daten zurückzugeben. Eine Berichtsserverfunktion hat nicht nur eine größere Toleranz für komplexe und langwierige Abfragen, sondern auch die Strategien zur Verbesserung der Leistung sind sehr unterschiedlich.
In einer transaktionsbasierten Anwendungsumgebung könnten Ihre Leistungsverbesserungsoptionen beispielsweise das Refactoring Ihrer gespeicherten Prozeduren und Tabellenstrukturen bis zum n-ten Grad oder die Entwicklung einer Caching-Strategie für kleine Mengen häufig angeforderter Daten umfassen. In einer Berichtsumgebung können Sie dies sicherlich tun, aber Sie können die Leistung noch stärker beeinflussen, indem Sie einen Snapshot-Mechanismus einführen, bei dem ein geplanter Prozess ausgeführt und vorkonfigurierte Berichte gespeichert wird und Ihre Benutzer auf die Snapshot-Daten zugreifen, ohne Ihre Datenbankebene zu belasten pro Anfrage.
All dies ist ein langatmiges Geschwätz, um zu veranschaulichen, dass die verwendeten Designprinzipien und -tricks je nach Rolle der DB, die Sie erstellen, unterschiedlich sein können. Ich hoffe, das ist hilfreich.
