Kann ein SQL Cursor übertragen werden?

[dholtmann]

Stimmt, der Aufruf klaut Einiges.
Wenn ich innerhalb der Prozedur alle Sätze fetche sind es noch 11Sekunden.

Die Grundidee war jedoch das read auf die Logische auszulagern, um alle Dateizugriffe zentral nur noch über ein Prozedur statt aus Programmen zu steuern.
Wenn es in Summe so viel Zeit kostet kann ich das bloß leider nicht nutzen.

[BenderD]

... gute 15.00 pro sec. sind doch ein guter Wert, was hast Du denn wirklich vor?

D*B

Hallo,
habe jetzt alles hinbekommen.
Meine Prozedur zum Lesen sieht wie folgt aus:


Bei ungefähr 600.000 Sätzen benötige ich ungefähr 38 Sekunden.
Native IO schafft das Ganze in 3-7 Sekunden.
Liegt das am Prozeduraufruf? Oder am Fetch?
Habt ihr Ideen wie das schneller funktioniert?

[dholtmann]

Nunja bisher laufen sämtliche Programme auf Logischen.
Egal, ob 1 Satz gelesen wird oder 25 Millionen.
Für zukünftige Programme wollte ich das halt generell auf diese Art auslagern.
Wenn ein Programm jetzt im Extremfall schon 2 Stunden läuft, habe ich einfach die
Befürchtung, dass es durch das vielfach langsame Lesen in Summe zu erheblichen Verzögerungen kommt.

[BenderD]

... wenn ein Programm jetzt 2h läuft, dann kann das nicht an den reads liegen, das müssten nach Deinen vorherigen Angaben dann ja 1 Milliarde reads sein. Bei SQL und read only, kann so ein Programm auch block weise fetchen, da dauern 1000 Sätze lesen ähnlich lang wie ein einzelner fetch. Im übrigen reduziert der sinnvolle Einsatz von SQL die Anzahl der reads auf einen Bruchteil im Vergleich zu rekord Löffel.

D*B

[Fuerchau]

Da kann ich Dieter nur zustimmen.
Wenn die für die Verarbeitung von 600.000 Sätzen 2 Stunden brauchst, sind 38 Sekunden zu vernachlässigen.
Das Ganze auf Basis von LF's aufzubauen ist sowieso Humbug da du für jede kleine Sortierung eine LF brauchst. Und dazu noch der Overhead für das ermitteln der Schlüsselfelder.
SQL in Prozeduren/Funktionen zu packen sollte generell eher auf Funktionen beschränkt werden und nicht die alten Filehandler ersetzen.
Der Nachteil ist eben durch die Übergabe von Strukturen wieder die Komplettwandlung aller Beteiligten.
Bei SQL kannst du den Vorteil, nur die Informationn zu lesen, die gerade benötigt werden, auf diesem Wege gar nicht nutzen.
Und was machst du mit Joins?
Kommen die bei dem Konzept nicht vor?
Ich mache z.B. einen Select auf Bewegungsdaten und hole mir per Join gleich die benötigten Stammdatenfelder dazu. Nach deiner Methode wäre das nicht zulässig.
Der Programmieraufwand wird dadurch nicht unerheblich größer.

Also Fazit:
Ich halte deinen Ansatz eher für eine Fingerübung.

[dholtmann]

Hm klar, mit den Logischen ist das keine Ideallösung,
aber ich hatte angedacht das optional zu regeln, so dass Leute die sich mit Views noch nicht wohl fühlen weiter diese benutzen können und Andere auf Views zugreifen.

Zum Punkt bezüglich des Wandelns,
Ich habe überlegt die eigentliche Fetchroutine in eine Copystrecke auszulagern, die dann ins Aufrufprogramm eingebunden wird.
Bekomm ich da Probleme? Hatte gehofft, dass neue Felder dann nur bis zum Wandeln nicht mit gefetcht werden, da halt die DS zu klein ist.
Lieg ich da falsch?

Wie weit das später wirklich Einsatz findet weiß ich auch noch nicht.
Momentan ist das für mich selbst mehr Forschung, da ich noch nicht lang mit Prozeduren und überhaupt embedded sql arbeite.

[BenderD]

... viel zu kompliziert gedacht!
- eine View ändert man niemals nicht!!!
- auf Tables greift man niemals nicht zu!!!
- wenn Felder dazu kommen, gibt es eine weitere View, wer die Felder braucht, nimmt die, wer nicht, eben nicht
- solange ich die vorhandenen Views darstellen kann, kann ich am Aufbau der Datenbank ändern (normalisieren!!!), ohne dass die Anwendungen was merken.
- hierbei können instead Trigger selbst joins updaten

D*B

PS: das mit den Copystrecken ist ein Rückschritt, was das kann, können subprocedures besser!!!

[Fuerchau]

Neben dem Problem, einen Cursor zurückzugeben.
Wenn das Programm nicht neu gewandelt wird, stirbt der Fetch da zu viele (oder zu wenige) Felder verfügbar sind. Der Fetch ist da statisch.

Vergiss den Ansatz SQL's in Prozeduren auszulagern.
Denke lieber darüber nach, "Geschäftslogik" in Prozeduren/Funktionen zu packen.
Du gewinnst nichts, wenn du die Aufrufe von SQL's wie die alten RLA-Zugriffe erzwingst.
Im Gegenteil, du verlierst nur (s.o. Performance)!

[BenderD]

... ich muss dich leider korrigieren, der Precompiler löst die Datenstrukturen alle in Einzelfelder auf und erstellt eine SQLDA. Beim select feldliste in Feldliste passiert rein garnix, solange man keine Felder entfernt oder inkomatibel ändert.
Beim select * werden nach Änderung an der Datei die Felder gemäß dieser SQLDA nach Reihenfolge in Felder gemapped, wenn alles verträglich ist, kommt eine warning hinterher, dass er zu wenige Host Variablen hatte. Mit anderen Worten: hängt man neue Felder hintendran, passt alles - ohne recompile.
Beim irgendwann erfolgenden Recompile passt alles, wenn man select * in die passende externe DS macht, oder beim select feldliste in feldliste angibt.

Datenzugriffsmodule, wie vom OP angesprochen ermöglichen eine sehr weitgehende Entkoppelung von Datenbank und Anwendungen und sind auf (fast) allen Plattformen weit verbreitet, lediglich die AS/400 community verharrt mit Macht im DV technischen Neolithicum.

D*B

[Fuerchau]

Korrektur zur Korrektur.
Dann erkläre ich mich genauer:
Wenn ich in einer Prozedur einen Cursor "Select *" zurückgebe und die rufenden Prozedur dann den Fetch mit diesem Cursor durchführt kann es zu dem beschriebenen Effekt kommen, wenn ich nur den Service bei Strukturänderungen neu erstellt habe. Ich habe somit keinerlei Vorteile.

Siehe
"ich habe überlegt die eigentliche Fetchroutine in eine Copystrecke auszulagern, die dann ins Aufrufprogramm eingebunden wird."

[BenderD]

... der cursor muss immer in derselben compileeinheit (module) declariert werden, in der auch der fetch verwendet wird - und dann gilt wieder genau das von mir oben geschriebene!

D*B

[dholtmann]

deklariert werden soll der Cursor auch in dem Module, wie BenderD schrieb.
Ich hab da auch was zum laufen gebracht und mich von Copystrecken wieder getrennt.
Aber entgültig zufrieden bin ich noch nicht. Ich melde mich, wenn ich wieder Zeit zum basteln hatte.