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

[hs]

Hallo Fuerchau,

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. Auch möchte ich die View in mehreren Abfragen verwenden, dann wäre jedesmal eine spezielle View erforderlich - was denke ich auch Performanceeinbußen zur Folge hätte (jedesmal dann, wenn ein Datensatz in das Lagerkonto eingefügt wird).

Teil B habe ich noch nicht verstanden. Kannst du den SQL mal für mein Beispiel schreiben?

Vielen Dank
HS

[Fuerchau]

Dein Problem ist die Where-Klausel in Verbindung mit dem Group By und die spätere Verknüpfung mit dieser.
where x in (....) ist das selbe wie where a=1 or x=2
Hier kann es helfen, einen Index mit der Transaktion als 1. Feld zu erstellen.
Also "Transaktion, Firma, Artikel, Datum desc".
Ich glaube aber nicht an den Optimizer, da Where und Groupby eigentlich 2 Indizes benötigt.

zu b)
Mit diesem "scalaren Subselect" wird genau 1 Satz über die Beziehung a.key = b.key ermittelt.
In deinem Fall hilft dies auch nicht da du ja eine zusätzliche Where-Klausel mit einer OR-Bedingung hast.

Ich fürchte, du musst mit dem Performancenachteil leben.

Alternativ würde ich dir einen Trigger empfehlen, der die benötigte Information in eine 2. Datei schreibt die dann nur noch Firma, Artikel, Datum enthält.

[andreaspr@aon.at]

Man müsste sich zunächst auch mal die Daten anschauen. Z.B.: wieviele Sätze gibt es mit TRANSAKTION in ('A', 'B').

Probier die Indice auch mit einer WHERE-Klausel:

CREATE INDEX TABINDx ON LAGERKONTO (FIRMA ASC) WHERE TRANSAKTION in ('A', 'B')

Du könntest auch probieren einen EVI anzulegen:
CREATE ENCODED VECTOR INDEX TABINDx ON LAGERKONTO (FIRMA ASC) WHERE TRANSAKTION in ('A', 'B')

lg Andreas

[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.