Więcej odpowiedzi na Twoje pytania:
1) Jesteś prawie na celu jak na kogoś, kto po raz pierwszy podchodzi do takiego problemu. Myślę, że wskazówki od innych na to pytanie do tej pory w dużej mierze go pokrywają. Dobra robota!
2 i 3) Uzyskiwana przez Ciebie wydajność będzie w dużej mierze zależeć od posiadania i optymalizacji odpowiednich indeksów dla konkretnych zapytań/procedur, a co ważniejsze od ilości rekordów. O ile nie mówisz o grubo ponad milionie rekordów w głównych tabelach, wydaje się, że jesteś na dobrej drodze do posiadania wystarczająco popularnego projektu, aby wydajność nie była problemem na rozsądnym sprzęcie.
To powiedziawszy i odnosi się to do twojego pytania 3, na początku prawdopodobnie nie powinieneś się zbytnio martwić o wydajność lub nadwrażliwość na ortodoksję normalizacyjną. Jest to serwer raportowania, który tworzysz, a nie zaplecze aplikacji oparte na transakcjach, które miałoby znacznie inny profil pod względem znaczenia wydajności lub normalizacji. Baza danych wspierająca aplikację do rejestracji i planowania na żywo musi być świadoma zapytań, których zwrócenie danych zajmuje kilka sekund. Funkcja serwera raportów ma nie tylko większą tolerancję dla złożonych i długich zapytań, ale strategie poprawy wydajności są znacznie różne.
Na przykład w środowisku aplikacji opartym na transakcjach opcje poprawy wydajności mogą obejmować refaktoryzację procedur składowanych i struktur tabel do n-tego stopnia lub opracowanie strategii buforowania dla małych ilości często żądanych danych. W środowisku raportowania z pewnością możesz to zrobić, ale możesz mieć jeszcze większy wpływ na wydajność, wprowadzając mechanizm migawek, w którym zaplanowany proces uruchamia i przechowuje wstępnie skonfigurowane raporty, a użytkownicy uzyskują dostęp do danych migawki bez obciążania warstwy bazy danych na podstawie żądania.
Wszystko to jest rozwlekłą tyradą, aby zilustrować, że zasady projektowania i sztuczki, które stosujesz, mogą się różnić, biorąc pod uwagę rolę db, którą tworzysz. Mam nadzieję, że to pomoże.
