Reporting environment: Best practices

[Dejan Vu]

Hi,
Ich habe heute ein neues Projekt übernommen: Eine Report-Sammlung für die SQL-Server Reporting Services von Microsoft.

Ich musste erst einmal meinen Schädel sehr kräftig gegen die Wand hämmern, denn der eigentlich geniale SQL-Programmierer hat alle Queries als ein einziges SELECT Statement, implementiert. Die Reports sind ziemlich komplex und damit auch die Queries. Eine Query sieht ungefähr so aus:

Code:

SELECT ....
  FROM (SELECT ... FROM 
    (SELECT ... FROM (
        SELECT * FROM Table JOIN foo...
         ) xy
      ) y
    )
   ) X JOIN (<der gleiche dreck wie oben>)

Also SELECTS in SELECTS in SELECTS. Feldlisten mit ca. 20-30 Einträgen, einige Felder wieder mit SELECT und CASE und WHEN und -alter Schwede-

So, eigentlich muss ich erstmal aufräumen, nur wie?

Ich habe das eigentlich immer so gemacht, das ich pro Report eine SP geschrieben habe (oder eine UDF, ist egal)
alle Parameter des Reports sind Parameter der SP/UDF.

Subselects werden vorher in temporäre Tabellen geschrieben oder als View abgebildet, wenn sie wiederverwenden werden können etc. Also DRY-Prinzip anwenden.

Ich hab mich nie drum gekümmert, wie echte Profis das machen, daher meine Frage: Wie macht ihr das? Oder: Gibt es überhaupt jemanden, der Erfahrung mit einem reinen SQL-Reporting Toolset hat (Views? UDF? etc.)

1. Schreibt ihr die Queries als Script im Reportgenerator oder -so wie ich- komplett als UDF/SP?
2. Verwendet ihr Aggregatfunktionen des Reporting-Tools (SSRS, Fast-Report etc.) oder bildet ihr alles in Queries ab?
3. Wo platziert ihr eventuelle Übersetzungen?
4. Wie würdet ihr das DRY-Prinzip im RDBMS umsetzen?