Hallo Leute,
ich stehe vor folgendem Problem (MS SQL Server 2005):
Hohe Anzahl aufeinander aufbauender Views mit UNIONS, CLR-Aggregatfunktionen, verschiedenen Joins. Etwa 40 Views bilden das "Resultat". Einen hab' ich mir mal inkl. seiner Abhängigkeiten exemplatisch ausgedruckt, das waren 11 Seiten A3 Querformat.
Ganz so schlimm ist es nicht. Die meisten Views laufen akzeptabel schnell. Lediglich etwa 8 Views müssten dringend schneller sein. Wobei die Antwortzeit bei etwa 15 Sekunden liegt. Vielleicht sogar wäre das noch akzeptabel, wenn nicht jeder User - die SQL-Queries sind völlig identisch - so lange darauf warten müsste, obwohl sich die zugrundeliegenden Tabellendaten nicht geändert haben!!!
Zunächst dachte ich daran, unique clustered indices für die views zu vergeben. Aber das war eine Sackgasse, weil daran derart viele Bedingungen geknüpft sind, dass ich damit höchstens in einfachen Spezialfällen beim Refactoring durchkommen würde. Und das sind genau die Views, die eh kein Problem machen.
Momentan bin ich ein bischen ratlos.
"Query Result Cache" gibt es anscheinend nur bei Oracle.
Vielleicht könnte ich mit Triggern die Views in Tabellen schreiben. Aber das wird vermutlich sehr aufwendig. Ausserdem weiss ich nicht genau,wie. Es sollen auch nicht alle Views, bei Änderung der zugrundeliegenden Tabellendaten neuberechnet werden, denn das würde viel zu lange dauern. Sondern ein View soll erst dann neu berechnet werden, wenn der erste User auf den View zugreift. Für die weiteren User soll es dann schnell gehen...
Wie macht man so etwas?
Viele Grüße,
Helmut
ich stehe vor folgendem Problem (MS SQL Server 2005):
Hohe Anzahl aufeinander aufbauender Views mit UNIONS, CLR-Aggregatfunktionen, verschiedenen Joins. Etwa 40 Views bilden das "Resultat". Einen hab' ich mir mal inkl. seiner Abhängigkeiten exemplatisch ausgedruckt, das waren 11 Seiten A3 Querformat.
Ganz so schlimm ist es nicht. Die meisten Views laufen akzeptabel schnell. Lediglich etwa 8 Views müssten dringend schneller sein. Wobei die Antwortzeit bei etwa 15 Sekunden liegt. Vielleicht sogar wäre das noch akzeptabel, wenn nicht jeder User - die SQL-Queries sind völlig identisch - so lange darauf warten müsste, obwohl sich die zugrundeliegenden Tabellendaten nicht geändert haben!!!
Zunächst dachte ich daran, unique clustered indices für die views zu vergeben. Aber das war eine Sackgasse, weil daran derart viele Bedingungen geknüpft sind, dass ich damit höchstens in einfachen Spezialfällen beim Refactoring durchkommen würde. Und das sind genau die Views, die eh kein Problem machen.
Momentan bin ich ein bischen ratlos.
"Query Result Cache" gibt es anscheinend nur bei Oracle.
Vielleicht könnte ich mit Triggern die Views in Tabellen schreiben. Aber das wird vermutlich sehr aufwendig. Ausserdem weiss ich nicht genau,wie. Es sollen auch nicht alle Views, bei Änderung der zugrundeliegenden Tabellendaten neuberechnet werden, denn das würde viel zu lange dauern. Sondern ein View soll erst dann neu berechnet werden, wenn der erste User auf den View zugreift. Für die weiteren User soll es dann schnell gehen...
Wie macht man so etwas?
Viele Grüße,
Helmut
Comment