Frage an die SQL-Experten: Performance bei View mit Group by

[BenderD]

das mit der View anstelle der QRY geht leider nicht, da es sich bei der Tabelle, mit der verknüpft wird, um eine temporäre Ausgabetabelle handelt.HS

... da liegt wohl der Hase im Pfeffer! Wieso wird denn da eine temp. Tabelle gebraucht?

[hs]

Möchte das im Detail nicht weiter ausführen, aber es ist eine komplexere Prozedur, in der mehrere Tabellen nacheinander abgefragt werden. Lässt sich nicht in einem QRY oder SQL erledigen.
Auch ist die temp. Tabelle nicht das Problem, Kopie wird immer dann erstellt wenn ich die VIEW verwende, d.h. mit irgendeiner anderen Tabelle verknüpfe.

[B.Hauser]

Das Problem liegt darin, dass Du Query verwendest!
Und Query ist NICHT SQL und wird bis einschließlich Release 7.1 von der alten Query Engine (CQE) verarbeitet.
Da helfen die ganzen neuen Indices mit und ohne WHERE-Bedingungen nichts.

Prüfe, ob das Query vielleicht durch QMQuery ersetzt werden kann. QMQuery basiert auf SQL und sollte von der neuen Query Engine (SQE) verarbeitet werden können und damit auch die neuen Indices nutzen können.

Birgitta

[hs]

Naja, grundsätzlich bringen Index schon auch Performance bei Queries. Nur halt nicht in diesem speziellen Fall.
Hab das gleiche mit einem SQL probiert, das geht sehr flott vonstatten, d.h. der Index wird sicher verwendet.
Denke ich werde bedarfsweise einige Queries mit SQL ersetzen (wird eh alles aus einer Prozedur aufgerufen).

Gruß und nochmals Danke für die Unterstützung
HS

[Fuerchau]

Als letzte Lösung:
Mach statt der View eine UDF, die per
select ....
order by ... Datum desc
fetch first 1 rows only

Genau diesen 1 Wert zurückgibt.

Du solltest allerdings nicht nach dem Ergebnis sortieren sonst hast du wieder das selbe Problem.
Die UDF kannst du dann überall an Stelle der View als Feld verwenden.

Ggf. klappt auch eine Procedure, die ein Resultset mit dem einen Satz zurückgibt, dann kannst du diese auch in Joins verwenden.

Da Joins je Satz ausgeführt werden könnte auch dieses performant sein.