Zu
Sql Server Spezifika kann ich nichts sagen.
Allgemein:
Jede Tabelle wird per se als View gewraped.Aus dem Report also kein Zugriff direkt auf Tabellen.
Wiederverwendbare Teilmengen werden als eigenständige Views aufgebaut.
„Core“ Informationen werden in „weiten“ Views (Breite & Tiefe) abgelegt (so weit/tief wie nötig).
Reports (+ Varianten) werden nach Möglichkeit auf identische Core Views aufgesetzt, deren Output dann reportspezifisch beschnitten wird.
Core Views gibt es ggF. in mehreren Hierarchiestufen (Aggregationsebenen oder was auch immer, die nicht idealer Weise nicht vermischt werden sollten bzw. erneut rauf/runtergerechnet werden)
Ein „riesen
SQL“ finde ich nicht dramatisch, wenn der Report auf nur eine Datenmenge anzeigt. Ist es entsprechend der Punkte oben in sinnvolle Views gegliedert, dann hat man idR eine gute Übersichtlichkeit.
Der weitgehende Einsatz von Views erlaubt natürlich auch, den Report Content relativ bequem zu ändern, ohne den Report selbst anzufassen. So kann man z.B. das zugrundeliegende Datenmodel abändern, ohne die Reports anfassen zu müssen.
Die Notwendigkeit von Temptables habe ich noch nie gesehen / gehabt, alles per View. In dem Zusammenhang: Da es sich ja um eine Reporting
DB handelt, böte sich hier im Rahmen des ETL noch die Möglichkeit, von Beginn an abzuspecken und wie der Name sagt zu transformieren.
UDF/SP:
Ich verwende in Views gerne Session Variables (als Parameter), das ist in der Form glaub ich Oracle spezifisch. Ähnliches lässt sich vermutlich per SP / UDF erreichen. Zusätzlich zur normalen View Verwendung, der „von außen“ auf die gewünschten Parameter eingeschränkt wird, hat man die Möglichkeit Parameter „innen“- also in der Viewdefinition-einzusetzen, sofern die entsprechende Entität nicht dargestellt werden muss (oder auch wenn sie dargestellt werden muss, aber einfach eine riesen Selektivität hat).
Indexed Views:
Kenne ich aus Oracle nicht, hier gibt es materialized Views, die man indizieren kann (und die eigentlich keine Views mehr sind). Würde ich bei einer Reporting
DB aber auch nicht mit loslegen, erst wenn es echte Performanceprobleme gibt und das ETL Ergebnis nicht weiter verschlankt werden kann.