Danke schon mal für die zahlreichen Anworten. Hier sind meine Anmerkungen dazu:

Ein Live-Update der Daten ist für unsere Zwecke nicht nötig und ist auch nicht unbedingt der Sinn eines BI-Systems. Ein abgeschlossener Zeitraum (z.B. bis einschließlich Vortag) ist völlig ausreichend. Und so wie ich die MQTs auf der AS/400 verstanden habe, gibt es auch gar keinen "REFRESH IMMEDIATE" bzw. "MAINTAINED BY SYSTEM". Ich würde hierfür einfach Planungsjobs einbauen, die dann komfortabel den "Refresh Table" auf die MQTs machen.

Ich habe gestern dann noch herausgefunden, dass diese ganzen Einschränkungen bei den Abfragen in der MQT nur zutreffen, wenn man "ENABLE QUERY OPTIMIZATION" verwendet. Ich habe dann mal auf "DISABLE" umgestellt und konnte meine MQT problemlos erstellen. Da wir die MQTs auch nicht in weiteren komplexen Abfragen verwenden, sondern komplett so wie sie sind ins BI-System laden, haben wir auch keine Performance-Einbußen.

Ich hab das jetzt mal getestet. Die ursprüngliche SQL-Abfrage (mit den UDFs) dauert in meinem Beispiel ca. 70 Sekunden. Gerade die UDFs sind es, die für die lange Laufzeit verantwortlich sind. Allerdings können wir die schlecht umstrukturieren, denn sie sind recht komplex. Deshalb haben wir sie ja in UDF ausgelagert. Nachdem ich die Daten in eine MQT geladen habe, dauert die Abfrage derselben Daten aus der MQT nur noch 0,3 Sekunden. Ich glaube ehrlich gesagt nicht, dass ich durch diverse Umstrukturierungen auf diese Antwortzeiten komme. Da finde ich es schon sinnvoller diese Daten in MQTs auszugliedern.

@Fuerchau: Was genau meinst Du mit "echtem BI-System"? Etwa die großen (Cognos, Hyperion, SAS, Board, etc.), die preislich im hohen 5-stelligen oder 6-stelligen Bereich liegen? Das kommt für uns sicher nicht in Frage. Ich verwende ja ein "echtes" BI-System und das kostet gar nix bzw. nur Kleinbeträge. Und was ich so in der ersten Testphase herausgefunden habe, ist es sehr mächtig und für unsere Zwecke völlig ausreichend.

Viele Grüße,
KM