Още няколко отговора на вашите въпроси:
1) До голяма степен сте в целта за някой, който се доближава до подобен проблем за първи път. Мисля, че насоките от други по този въпрос досега го покриват до голяма степен. Добра работа!
2 и 3) Ударът в производителността, който ще постигнете, до голяма степен ще зависи от наличието и оптимизирането на правилните индекси за вашите конкретни заявки/процедури и по-важното от обема на записи. Освен ако не говорите за повече от милион записа във вашите основни таблици, вие изглежда сте на път да имате достатъчно мейнстрийм дизайн, че производителността няма да бъде проблем на разумен хардуер.
Въпреки това, и това се отнася до вашия въпрос 3, с началото, което имате, вероятно не трябва да се притеснявате прекалено за производителността или свръхчувствителността към нормализирането на ортодоксията тук. Това е сървър за отчитане, който изграждате, а не бекенд на приложение, базиран на транзакции, който би имал много различен профил по отношение на важността на производителността или нормализирането. База данни, която поддържа приложение за регистрация и планиране на живо, трябва да има предвид заявките, които отнемат секунди, за да върнат данни. Функцията на сървъра за отчети не само има по-голяма толерантност към сложни и дълги заявки, но и стратегиите за подобряване на производителността са много различни.
Например, в среда на приложения, базирана на транзакции, вашите опции за подобряване на производителността могат да включват рефакторинг на вашите съхранени процедури и структури на таблици до n-та степен или разработване на стратегия за кеширане за малки количества често търсени данни. В среда за отчитане със сигурност можете да направите това, но можете да окажете още по-голямо въздействие върху производителността, като въведете механизъм за моментна снимка, при който планиран процес се изпълнява и съхранява предварително конфигурирани отчети и вашите потребители имат достъп до данните за моментната снимка без напрежение върху нивото на вашата база данни на на база заявка.
Всичко това е дълготрайна ревност, която илюстрира, че принципите и трикове на дизайна, които използвате, може да се различават предвид ролята на базата данни, която създавате. Надявам се това да е полезно.
