Expertenfrage zur Performance

[andreaspr@aon.at]

Mein erster Gedanke wäre jetzt:
Programmierung in Free;
SETLL/READE bzw. CHAIN machen(da ich nicht genau weiß, an welchem Rädchen man bei SQL drehen kann, damit es schneller geht als Reade/chain);
Join-File beibehalten bzw. neue Join-Files(wenn Dateien drin sind die ich nicht brauche) oder LF's mit Selcet/ommit;

Hi,
in Sql (falls man es einsetzen will) würde ich es so machen:
Je nachdem was du machen möchtest kannst du einen Sql-Cursor erstellen. Wenn du im Ablauf nur EIN chain machst, reicht meines erachtens auch ein Select sp1 Into :v1 From Tab1 where ...
Wenn du das gleiche chain öfters benutzt, kannst du den Sql-Cursor verwenden. (chain wäre dann ein Open Cursor & Fetch MyCursor Into :v1)
Ein Select ... Into ... ist nicht grad der schnellste weg um an Daten zu kommen.

Wenn du LFs mit Select/Ommit benützen möchtest, ist jedoch das chain besser, da diese LFs nur mit der alten Sql-Engine verarbeitet werden können.
Andernfalls in SQL einen Index oder View erstellen (ab 6.1 sogar bis zu einem gewissen Grad kombiniert)

Grundsätzlich gilt schon, dass ein einzelner Chain schneller ist als SQL. Wenn du direkt auf die LFs zugreifst ist das schneller als wenn SQL den besten Zugriffspfad erst ermitteln muss. Zumindest solange du nur einzelne Sätze einer Tabelle lesen gehst.
Sobald du jedoch eine große Anzahl an Sätzen verarbeiten musst schaut das Ganze wieder etwas anders aus. Denn die Erstellung des Zugriffspfades in SQL dauert nur ein paar Millisekunden. Da ist dann die Frage ob der Zugriffspfad nur ein paar mal erstellt werden muss oder 1 Mio mal. (Bei 1 Mio mal hat man sowieso einen Entwicklungsfehler).
Der Vorteil von SQL wäre, dass du später zb MQTs oder Indices erstellen kannst die dann gleich von SQL benutzt werden können. Bei chain usw. musst du von Anfang an Fix deine Zugriffspfade kennen und bestimmen.

Ich würde kein overlay verwenden nur um die LIBL auszutrixen, sondern die LIBL bzw. CURLIB entsprechen anpassen. Fehler lassen sich dadurch schneller und besser finden.

[votch]

Hallo Andreas und vielen Dank schon mal.

schon wieder was dazu gelernt in SQL :-), aber in diesem spez. Fall werde ich es dann wohl per chain machen, da es fast immer nur ein chain ist und ich keine großen Datenmengen lesen muss.

Von den int. Dateiüberschreibungen bin ich eigentlich auch kein Fan, aber hier wird das standardmäßig so gemacht und wenn es jetzt keinen Grund gibt vom Standard abzuweichen(z.B. dass es schneller wäre per Lib-List-Änderung), wird das Abweichen vom Standard leider nicht so gerne gesehen.

Gruß,
Roland

[andreaspr@aon.at]

Hi Roland,
welche OS-Version hast du? Ab 6.1.1 gibt es auch möglichkeiten eines temporären Filesystems im IFS. Das hat auch nette Performancevorteile.
lg Andreas