SQL UDF erstellen - Best practices

[Fuerchau]

Also auch in RPG kann ich ja mit CLOB's für JSON umgehen um diese bereitzustellen.
Allerdings sollte man sich hier tatsächlich überlegen, ob für Webservices hier mehr als 100KB, max. ggf. 2MB an Daten zurückgegeben werden müssen.
Da wird vom Client auch gerne ein Paging verwendet, dass ungeführ dem Umfang einer Browser-Seite entspricht (20-50 Zeilen), Page 1 - N.

Die Crux hier ist tatsächlich, dass für die Kommunikation zwischen RPG und Client eine Schicht eingezogen werden muss (Node.js, Java, Python, PHP, ...), um die Businesslogik nicht auch noch neu schreiben zu müssen. Und was bietet sich da einfacher an als SQL?
Ggf. kann man Services in RPG ja auch via "dcl-f .... HANDLER(XXX)" bauen. Im Handler kann der Web-Service laufen und per RPG-READ/WRITE die Kommunikation.
Da würde zwar je Client ggf. ein eigener Server-Job benötigt, aber das ist performanceseitig das geringste Problem.
Da SQL intern multithreaded arbeiten kann, ILERPG aber nicht, verlangsamen externe UDF's das System maßgeblich.

[Andreas_Prouza]

Ich habe da eher den pragmatischen Ansatz dazu.
Wenn man SQL hört, denken alle gleich an DB-Zugriffe und dementsprechend darf da keine Business-Logik hinein.
Ich trenne hier viel mehr zwischen Daten-Zugriffe & Verarbeitung.
Beides kann in RPG, in SQL, Python, Java & Co geschrieben werden können.

Damals was die Diskussion: Wie viel Char darf eine Spalte/Variable haben.
Dieser Gedanke kommt aus dem Zeitalter als die Systeme noch KB oder MB RAM hatten.
Die gleiche Diskussion sehe ich heute immer wieder mit DB Zugriffe.
Wenn ich es schaffe diese Zugriffe aus der Business-Logik raus zu nehmen, ist es egal was in welche Sprache dies gemacht wird

[Fuerchau]

"Wenn ich es schaffe diese Zugriffe aus der Business-Logik raus zu nehmen" meinte Dieter ja auch;-).

[dschroeder]

Anfangs haben wir bei Webservices auch angenommen, dass es reicht, wenige MB (mit RPG) zurückzugeben. Für Listen mit mehr Daten haben wir dann Paging eingebaut. Wir haben aber das Problem, dass wir einige Business-Objekte haben (z.B. Versicherungsverträge), die so komplex sind, dass das 2 oder 3 MB nicht reichen, um ein Objekt zu beschreiben. Wird müssten dann unsere Business-Objekte in kleinere logische Objekte aufspalten oder wird müssten unsere großen Objekte als Byteketten betrachten und dass dann im Paging herausgeben oder wir müssten die Speichergrenze mittels SQL umgehen. Und das ist im Moment der Ansatz, den wir verfolgen.

[BenderD]

Anfangs haben wir bei Webservices auch angenommen, dass es reicht, wenige MB (mit RPG) zurückzugeben. Für Listen mit mehr Daten haben wir dann Paging eingebaut. Wir haben aber das Problem, dass wir einige Business-Objekte haben (z.B. Versicherungsverträge), die so komplex sind, dass das 2 oder 3 MB nicht reichen, um ein Objekt zu beschreiben. Wird müssten dann unsere Business-Objekte in kleinere logische Objekte aufspalten oder wird müssten unsere großen Objekte als Byteketten betrachten und dass dann im Paging herausgeben oder wir müssten die Speichergrenze mittels SQL umgehen. Und das ist im Moment der Ansatz, den wir verfolgen.

... das hört sich für mich alles nach Gebastel an. Einen Versicherungsvertrag in ein SQL Statement zu packen oder per SQL Programm zusammen zu klappern halte ich für ein anspruchsvolles Unterfangen. Wenn ich mir das noch in einer Architektur von Services vorstelle, wird mir flau im Magen dabei.
Das mit dem Debug ist doch nur die halbe Wahrheit, wie will ich denn da Fehlersituationen im richtigen Leben beikommen? m. E. geht da nichts an einem ausgeklügelten logging vorbei, das ich für Analysezwecke feinkörnig steuern kann (log4j oder gleichwertiges lässt grüßen). SQL ist da als Programmiersprache völlig ungeeignet.

D*B

[Fuerchau]

Mit dem Einsatz von BLOB/CLOB/DBCLOB kann ein Dokument 2GB groß werden und auch von RPG mit SQL-Substr bearbeitet werden. Sicherlich kein einfaches Unterfangen aber konzeptionell machbar.
Auch die SQL-Treiber unterstützen LOB's um sie mit anderen Sprachen dann abgreifen zu können.
Ich lese via SQL Dateien aus dem IFS auch als CLOB / BLOB ohne Probleme.