embedded-SQL fetch über mehrere Dateien

[zannaleer]

Hallo Forum,

wie muß eine Datenstruktur aufgebaut sein, wenn beim embedded-SQL auf mehrere Dateien zugegriffen wird?
Greife ich nur auf eine Datei zu, baue ich die Ergebnis-Datenstruktur für das "fetch into" genauso auf, wie die Datei. Wie muss ich diese aber aufbauen, wenn über eine join-Anweisung mehrere Dateien verknüpft werden?

Gruß
Alexander.

[mk]

HAllo Alexander,

die Datenstruktur muss genauso aussehen
wie die Felder in der Select klausel.

Gruss Michael

[zannaleer]

Hallo Michael,

das weiß ich und genau das ist ja das Problem. Ich möchte nicht jedes einzelne Feld der Datenstruktur manuell definieren, sondern so ähnlich wie bei einer Datenstruktur, die die Felder nur einer Datei enthält mit "extfile" arbeiten.

Gruß
Alexander

[Fuerchau]

Irgendwo ist der manuelle Aufwand nötig.
Entweder definierst du eine PF per DDS, die genau die Struktur deines Joins beinhaltet, dann kannst du diese als externe DS übernehmen oder du definierst die Felder halt in einer eigenen Struktur.
Wenn du die einzelnen Felder nicht explizit ausdefinieren wills (also Typ und Länge) kannst du per LIKE (ILERPG) die Definition übernehmen.

Woher soll SQL denn die Struktur kennen, wenn sie nicht definiert ist ?

[zannaleer]

Ich habe mir halt gedacht, dass es so oder ähnlich funktionieren könnte:

 * Datenstrukturen                                                                
d Ds_AAP        e ds                  extname(AAP)                                
d Ds_AAI        e ds                  extname(AAI)                                
d Ds_AAK        e ds                  extname(AAK)                                
                                                                                  
d Ds_AAI_Sql      ds                  occurs(7)                                   
d Ds_AAP                                                                          
d Ds_AAI                                                                          
d Ds_AAK 

Und die Datenstruktut Ds_AAI_Sql ist die, die ich beim fetch into verwende.

[Fuerchau]

Damit kann SQL nun mal nicht zurechtkommen.
Du kommst um eine explizite Definition (egal ob extern oder intern) der Felder nicht herum.
Es ist auch nicht gerade von Vorteil, beim Join mit einem "SELECT *" zu arbeiten.
Überhaupt sollte man beim SQL nur genau die Felder auswählen, die man auch tatsächlich braucht.
Dann sind spätere Dateiänderungen/-erweiterungen nicht mehr kritisch.

[BenderD]

Hallo,

schnöderweise so:
CREATE VIEW myview as ....
und dann einfach als externe DS mit EXTNAME(MYVIEW) im Programm deklarieren.

mfg

Dieter Bender

Hallo Forum,

wie muß eine Datenstruktur aufgebaut sein, wenn beim embedded-SQL auf mehrere Dateien zugegriffen wird?
Greife ich nur auf eine Datei zu, baue ich die Ergebnis-Datenstruktur für das "fetch into" genauso auf, wie die Datei. Wie muss ich diese aber aufbauen, wenn über eine join-Anweisung mehrere Dateien verknüpft werden?

Gruß
Alexander.

[Fuerchau]

Dann kann ich auch direkt mit "select * from myview" arbeiten

[BenderD]

... und bei Änderungen am Dateiaufbau etc. ändert sich immer nur die View und nicht das Programm (siehe auch Thread Dateiänderung ohne recompile)

mfg

Dieter Bender

Dann kann ich auch direkt mit "select * from myview" arbeiten

[B.Hauser]

Ein Recompile ist allerdings nur dann nicht erforderlich, wenn einzelne Felder ausgewählt und in einer Datenstruktur zusammengefasst wurden.

Wird eine externe Datenstruktur und SELECT * verwendet, ist ein Recompile wie bei anderen Datei-Änderungen erforderlich.

@Zannaleer
Du kannst auch folgendes versuchen:
Die einzelnen Dateien als Externe Mehrfach Datenstrukturen definieren und beim Fetch diese Datenstrukturen aufzählen.

d Ds_AAP        e ds                  extname(AAP) occurs(7)        
d Ds_AAI        e ds                  extname(AAI) occurs(7)
d Ds_AAK        e ds                  extname(AAK) occurs(7)

c/EXEC SQL  FETCH Next from MyCursor for 7 Rows
C+          into :DS_AAP, :DS_AAI, :DS_AAK
C/END-EXEC 

Diese Lösung funktionniert zumindest beim Single Row Fetch, beim Multiple Row Fetch habe ich es noch nicht probiert.

Die bessere Lösung ist allerdings eine SQL-View zu benutzen.
Dies vereinfacht nicht nur den Code, sondern ist zudem auch noch performanter als ein direkter JOIN im Programm.

Birgitta

[BenderD]

Hallo,

sorry, Einspruch in zwei Punkten:
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.
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!

mfg

Dieter Bender

Ein Recompile ist allerdings nur dann nicht erforderlich, wenn einzelne Felder ausgewählt und in einer Datenstruktur zusammengefasst wurden.

Wird eine externe Datenstruktur und SELECT * verwendet, ist ein Recompile wie bei anderen Datei-Änderungen erforderlich.

@Zannaleer
Du kannst auch folgendes versuchen:
Die einzelnen Dateien als Externe Mehrfach Datenstrukturen definieren und beim Fetch diese Datenstrukturen aufzählen.

d Ds_AAP        e ds                  extname(AAP) occurs(7)        
d Ds_AAI        e ds                  extname(AAI) occurs(7)
d Ds_AAK        e ds                  extname(AAK) occurs(7)

c/EXEC SQL  FETCH Next from MyCursor for 7 Rows
C+          into :DS_AAP, :DS_AAI, :DS_AAK
C/END-EXEC 

Diese Lösung funktionniert zumindest beim Single Row Fetch, beim Multiple Row Fetch habe ich es noch nicht probiert.

Die bessere Lösung ist allerdings eine SQL-View zu benutzen.
Dies vereinfacht nicht nur den Code, sondern ist zudem auch noch performanter als ein direkter JOIN im Programm.

Birgitta

[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