View wie eine LF behandeln?

[MederA]

Hallo zusammen,

wir haben jetzt nach langem den Wunsch entwickelt einige Prozesse schlanker zu machen und dabei kam die Frage auf, ob man eine View überall wie eine LF behandeln kann.

Der genaue Hintergrund:

JSON Daten werden abgeholt und bisher in eine normale, mit SQL erstellte Tabelle geschrieben. Mit einem plumpen "insert into Libl/Tabelle" im RPG Programm.
Der Kollege kam jetzt auf die Idee: Dann mach doch für jedes Einspielprogramm eine eigene Logische, dann geht das schneller und keiner muss auf den anderen warten und es staut sich weniger.

Jetzt weis ich, dass ich eine View im Programm wie eine alte LF als Datei behandeln kann und daraus Daten auslesen kann. Die Frage ist aber: Kann ich auch einfach Daten hinzufügen?
Nicht mit einem write sondern wirklich mit einem insert into ?

Das Internet konnte mir die Frage nicht beantworten bisher - Hab ihr da eine für mich?

Liebe Grüße
Andrea

[Robi]

In die View so ohne weiteres nicht.
Dazu musst du, so meine ich, SQL Trigger haben.
Aber warum schreibst du nicht die PF?

[MederA]

Das mache ich momentan schon.
Ich habe 7 Programme die getrennt von einander in die Tabelle schreiben, aber halt alle zeitgleich laufen und damit auch fast zeitgleich in die Tabelle schreiben. Nanosekunden unterschiede vielleicht, wenn man sich den Timestamp in der Datei anschaut.

Von einem SQL Trigger hab ich gehört, verwendet habe ich noch keinen.

[Robi]

Ist den das 'gleichzeitige' Schreiben in die PF ein Problem?
Oder habt ihr Commitment an?

[dschroeder]

Hallo Andrea,
es geht mir wie Robi: Ich habe dein Problem auch noch nicht verstanden. Mit Insert Into schreibt man immer in eine physische Tabelle. Wenn man weitere logische Tabellen oder Indices auf die physische Tabelle legt, wird das Schreiben eher langsamer. Eine View dürfte das Schreiben nicht verlangsamen. Aber sie nützt auch nichts beim Schreiben.

Was schreibt ihr denn in die Datei? Du nanntest JSON Daten. Schreibt ihr clobs in die Tabelle und das dauert lange? Ich sehe es wie Robi: Dass mehrere Programme gleichzeitig in eine Tabelle schreiben, ist völlig normal und sollte erstmal kein Performance Problem sein.

LG, Dieter

[RobertMack]

Das mache ich momentan schon.
Ich habe 7 Programme die getrennt von einander in die Tabelle schreiben, aber halt alle zeitgleich laufen und damit auch fast zeitgleich in die Tabelle schreiben.

Ich würde auch mal durch die 7 Programme gehen und prüfen, welcher Read/Chain durch Read(N) und Chain(N) ersetzt werden kann...

[dschroeder]

Vielleicht schreiben die 7 Programme nicht einfach nur, sondern lesen auch Daten. Wenn da ein Index / eine LF fehlt, kann das natürlich dauern. Das ist dann aber kein Schreibproblem.
Ich denke, ohne weitere Infos kann man hier nicht weiterhelfen.

[B.Hauser]

Zunächst einmal, was ist eine View?
Eine View ist nichts anderes als ein gesichertes SQL (SELECT) Statement. In einer View kann alles hinterlegt werden, was in einem SELECT-Statement zulässig ist, mit Ausnahme des ORDER BY.
Eine View ist immer ungeschlüsselt (deshalb ist auch der ORDER BY nicht zulässig).
Mit Hilfe von Views kann die Komplexität vom Programmen reduziert werden, da der komplexe SQL Code in einer View versteckt ist und auch in mehereren Programmen verwendet wird.
Bei der Ausführung/Verwendung einer View wird das gesicherte SELECT-Statement vom Optimizer aufgelöst (also an die Stelle gesetzt, an der die View aufgerufen wurde) und dann erfolgt die eigentliche Optimierung.
Das schöne bei SQL ist, die Sätze werden gefunden. Ohne die geeigneten Zugriffswege (Indices, geschlüsselte logische Dateien) wird erfolgt ein Table Scan (alles Sätze in der Tabelle/physichen Datei werden gelesen) oder wenn es keine andere Möglichkeit gibt, wird ein MTI (maintained Temporary Index) erstellt. Beides ist zeitaufwändig.
Views können überall verwendet werden, wo Tabellen oder Physische Dateien verwendet werden. Auch mit Native I/O. Da Views immer ungeschlüsselt sind und der Optimizer entscheidet, macht die Verwendung von Views mit Native I/O nur dann Sinn, wenn die Daten in keiner bestimmten Reihenfolge verarbeitet werden müssen.
Da SQL unheimlich mächtig ist, sind View ein gutes Mittel um Komplexität zu verstecken und um den Source Code (der ggf. in mehreren Programmen, die ggf. auch in unterschiedlichen Programmiersprachen geschrieben sind) zu minimieren und die Logik an einer Stelle (in der View) zu zentralisieren, was wiederum die Wartung vereinfacht.
Views sind jedoch kein Mittel um die Verarbeitungsgeschwindigkeit zu beeinflussen. Dazu sind entsprechende Zugriffswege erforderlich.
Es ist natürlich auch möglich in eine View zu schreiben (wie in eine logische Datei - mit native I/O und SQL), solange, die View nur auf eine Tabelle zugreift und keine Joins oder Group Bys o.ä. enthält, die eine View nicht mehr "updatable" macht.

Du kannst natürlich auch eine View in einem INSERT Statement verwenden also z.B.:
INSERT into View2 as (SELECT ... from VIEW1)
... aber Du kannst keine View um ein INSERT-Statement bauen. Eine View basiert immer auf einem SELECT-Statement.

Birgitta

[Fuerchau]

"Der Kollege kam jetzt auf die Idee: Dann mach doch für jedes Einspielprogramm eine eigene Logische, dann geht das schneller und keiner muss auf den anderen warten und es staut sich weniger."

Wie kommt der auf so eine Idee?
Dies ist so auf der IBM i nicht möglich. Es können gleichzweitig 1000de Jobs in eine Tabelle/PF schreiben ohne dass irgend ein Job warten muss.
Wenn der Kollege den Microsoft SQL-Server meint, dann kommt es bei sog. Snapshot-Transactions zu Tablelocks, die tatsächlich jeden anderen Zugriff blockieren, bis die Transaktion abgeschlossen ist (LOck-Escalation)

Welchen Vorteile soll das also bringen, zumal alle Views diesen Zwecks auf dieselbe Tabelle/PF verweisen.

Daher wiederhole ich obige Frage:
Welches Problem habt ihr tatsächlich und wie drückt sich dieses aus?