embedded-SQL fetch über mehrere Dateien

[B.Hauser]

1. wenn die View dasselbe Format liefert, dann ist es völlig Wurscht wo die Daten wirklich herkommen, dann brauchts kein Recompile! Sprich: man ändert eventuell im View Layer und nicht das Programm.

Vielleicht hatte ich mich unklar ausgedrückt:
Ein Recompile ist erforderlich, wenn sich die Anzahl und/oder Reihenfolge von Feldern in einer View ändert und zur Ausgabe eine externe Datenstruktur über die View verwendet wird.
Die externe Datenstruktur wird zur Compile-Zeit in das Programm/Modul-Objekt eingebunden!
Wird also eine Datei um mehrere Felder erweitert und in der View werden alle Felder verwendet (CREATE VIEW as SELECT a.*, b.* from a join b on ...) muss auch die Ausgabe-Datenstruktur verändert werden, also RECOMPILE.
Werden einzelne Felder ausgewählt (bei der Erstellung der View oder im Programm/Modul) ist ein Recompile nicht erforderlich.
Ein Recompile ist auch dann nicht erforderlich, wenn sich nur Where-Bedingungen in einer View ändern.

2. Ob ich eine View habe, oder einen Join mache, das ist von der Performance her Banane. Die (SQL) View hat keinen Zugriffspfad und enthält auch keinen Zugriffsplan, der kann erst bei dem Select im Programm berechnet werden, da hier ja auch noch eine Order By Klausel stehen kann!

Hast Du das analysiert oder erzählst Du nur was in den Büchern steht?

In der Theorie hast Du recht. Bei der Analyse (unter Release V5R2M0) von SQL-Statements über den iSeries Navigator, PRTSQLINF u.a. habe ich andere Erfahrungen gemacht.

Voraussetzung ist, dass entsprechende Indices angelegt sind und auch vom Optimizer verwendet werden.

Die langsamste Variante ist die Verwendung von DDS-beschriebenen Join-Files, da die Dateibeschreibung zunächst aufgedröselt wird, das SQL-Statement neu geschrieben wird und dann die entsprechenden Indices gesucht werden.
Soweit so klar!

Ein Join der direkt im Programm (oder auch interaktiv) ausgeführt wird ist wesentlich schneller, da meistens kein Rewrite des SQL-Statements erforderlich ist und die Indices direkt ermittelt werden können.

Wird statt des direkten Join eine SQL-View verwendet halbiert sich die Zeit. Dies ist das Ergebnis zu dem ich nach der Analyse von bestimmt schon hunderten von SQL-Statements gekommen bin.
Woran das liegt kann ich nicht sagen, in der Literatur habe ich diesbezüglich noch nichts gefunden und auch aus Rochester habe ich bisher keine Antwort zu diesem Phänomen.

Zugriffs-Pläne? Statistiken??
Es ist müsig darüber zu spekulieren, besonders, weil unter Release V5R2M0 Joins noch über die alte CQE erfolgen. In Release V5R3M0 mit der neuen SQE kann alles ganz anders und u.U. nicht unbedingt besser sein.

Und ORDER BYs sollte man eh nur verwenden wenn's nicht anders geht. Bei der Suche nach dem optimalen Index werden die Sortierfolgen sowieso erst nach Where, Join und Group By Bedingungen berücksichtigt und nicht selten wird eine temporäre Datei erstellt und über diese ein temporärer Index gelegt.

Birgitta