Ich vergaß zu erwähnen, das es sich um eine Reporting-
DB handelt. Täglich werden die Daten aus der Produktiv-
DB in die Reporting-
DB übernommen. Die Produktiv-
DB besteht nur aus
XML-Records und im ersten Schritt wurde eigentlich nur die
XML-Struktur in der Reporting-
DB abgebildet. Jeden Abend werden alle Änderungen in die Reporting-
DB übernommen (quasi ETL)
Die redundanten Subselects werde ich vermutlich (zunächst) in indexed Views auslagern. Dann habe ich eine direkte Kontrolle über den Inhalt und kann diesen -speziell während der Designzeit- verändern und erweitern. Nachteil an den Indexed Views ist aber, das die verwendeten Tabellen alle im gleichen Tablespace liegen müssen und verwendete Views ebenfalls mit Schemabinding (also als indexed Views) kompiliert sein müssen. Indexed Views sind also viral.
Ich glaube, wir machen das über Indexed Views, und ersetzen diese später durch Tabellen gleichen Namens. Aber sicher bin ich mir noch nicht.
Bezüglich des Report-Codes (die riesigen SELECTs, die als Skript in der Report-Definition RDL lagern) sind wir uns eigentlich einig, das sie in eine SP gehören, aber bei der Versionierung hapert es noch. Es wäre blöd, wenn der Report für eine
Query die Version 1.23 erwartet, aber auf dem Server die SP in Version 1.21 vorliegt. Das muss unterbunden werden. Mal sehen, was uns da einfällt (Versionsnummer in SP und Vergleich o.ä.).