RPGLE - SQL

[christian_lettner]

Hallo!

Wir arbeiten derzeit bei allen Programmen mit CHAIN bzw. READ-Schleifen.

Kann mir jemand die Vor- bzw. Nachteile dieser Methode, bzw. der Verwendung von SQL in RPGLE aufzählen.

Bei welchen Programmen macht der Einsatz von SQL überhaupt Sinn? Bei Übersichten, Wartungsprogrammen, Batch-Programmen, ...
Ist mit SQL eine Übersicht mit 5,6,7,.... unterschiedlichen Auswahlfeldern überhaupt halbwegs unkompliziert realisierbar?
Wie sieht es mit der Performance der beiden Methoden aus.
Nimmt die Objektgröße bei Verwendung von SQL gravierend zu? Ist deshalb interessant, weil wir permanent Updates bei Kunden installieren müssen.

Hat jemand vielleicht ein einfaches Beispiel für die Verwendung von SQL mit dynamischer Auswahl, bzw. Insert oder Update.

Bin für jede Info dankbar, da ich unseren Programmierstiel etwas modernisieren möchte.

mfg Chris

[BenderD]

Hallo,

ein paar Anmerkungen aus meiner subjektiven Sicht:

- entweder man nimmt SQL oder Record Level Access, Mix sollte immer nur Übergang sein (Mix ist auch ein Bremser und Ressourcenfresser und tödlich für die Wartbarkeit).

- SQL ist ein übergreifender Standard, sowohl was Datenbanken betrifft, als auch was Programmiersprachen angeht

- ein Umstieg auf SQL sollte man nur machen, wenn man auch bereit ist seinen Programmierstil zu ändern in Richtung auf Entkoppelung von Anwendung und Datenbank. Sprich weg vom Navigieren über Tabellen, hin zu Mengen orientierter Verarbeitung. Daraus resultieren die entscheidenden Unterschiede:
-- höhere Flexibilität bei besserer Wartbarkeit durch die Möglichkeit von dynamischen Auswahlen.
-- komplexe Auswahlen, wie angeführt werden deutlich einfacher
-- in der Summe bessere Performance durch klarere Logik, weniger Mehrfachverarbeitung und besseres Verhältnis von asynchronem und synchronem lesen, bei höherer Last für den Rechner (man bekommt nix geschenkt, auch hier nicht!!!).
-- ich habe mich eigentlich nie für die Objektgrößen interessiert, sollte mich nicht wundern, wenn die SQL Runtime unnötigerweise in die Programme eingeht und diese aufbläht, in der Summe dominieren hier aber andere Faktoren, wie Modularisierung (je besser, desto kleiner das Ganze, in Monolithen ist alles doppelt und dreifach) und entscheidend ist doch allenfalls die Größe der Updates und da geht es ebenfalls um Modularisierung (Zentralisierung von Änderungshäufigkeit).

- Beispiele findet man sicher in den Fragestellungen in diesem Forum und in den IBM Publikationen, wobei da vieles leider nicht gerade modularen Stil abbildet.

mfg

Dieter Bender

Hallo!

Wir arbeiten derzeit bei allen Programmen mit CHAIN bzw. READ-Schleifen.

Kann mir jemand die Vor- bzw. Nachteile dieser Methode, bzw. der Verwendung von SQL in RPGLE aufzählen.

Bei welchen Programmen macht der Einsatz von SQL überhaupt Sinn? Bei Übersichten, Wartungsprogrammen, Batch-Programmen, ...
Ist mit SQL eine Übersicht mit 5,6,7,.... unterschiedlichen Auswahlfeldern überhaupt halbwegs unkompliziert realisierbar?
Wie sieht es mit der Performance der beiden Methoden aus.
Nimmt die Objektgröße bei Verwendung von SQL gravierend zu? Ist deshalb interessant, weil wir permanent Updates bei Kunden installieren müssen.

Hat jemand vielleicht ein einfaches Beispiel für die Verwendung von SQL mit dynamischer Auswahl, bzw. Insert oder Update.

Bin für jede Info dankbar, da ich unseren Programmierstiel etwas modernisieren möchte.

mfg Chris

[mwithake]

Hallo Chris,

ich nutzte SQL hauptsächlich und in hohen Maße für Abfragen, also Listenerstellung oder Subfile-Füllungen oder wenn es um Summenberechnungen, Gruppenbildung etc. geht. Es geht wesentlich fixer und flexibler als mit READ-Schleifen, da man hier einfach mal die Sortierungen auswechseln kann oder einfach eine Tabelle zur Abprüfung per JOIN mit hinzunehmen kann. Ich kann mir Listenerstellung ohne SQL nicht mehr vorstellen.

Wartungsprogramme für Einzelsätze schreibe ich weiterhin mit CHAIN, UPDATE, WRITE-Statements weil ich hier die Zugriffssteuerung (Satzblockierung etc.) einfacher finde als mit SQL. Ich sehe auch kein Problem im mixen der beiden Varianten.

Wichtig für den Einsatz von SQL finde ich ein gutes Datenbankdesign, vornehmlich bei der logischen Dateien bzw. Indizies. So sollten in logischen Dateien keine Satzauswahlen enthalten sein (COMP etc.) da diese Dateien dann nicht von SQL verwendet werden.

Fang einfach mal an, kleine und einfache Programme auf SQL umzustellen, auch wenn es nur die Ersetzung eine READ-Schleife ist. Formuliere im SELECT die Felder, die Du benötigts. Verwende nicht SELECT * mit der Übergabe in eine externe Datenstruktur die auf die ursprüngliche Datei definiert ist. Der Aufwand erscheint für eine einfach READ-Schleife hoch, doch die Zusatzvorteile, die später durch Verwendung zusätzliche SQL-Elemente hinzukommen, machen das allemal wieder wett.
Versuche dann nach und nach auch Abfragen auf andere Dateien in der SQL-Abfrage mit einzubinden (z.B. Lesen einer Auftragsdatei mit Nationsabfrage im Kundenstamm)

Wenn Du einige Programm umgestellt hast, lese mal die IBM-Handbücher zu SQL auf der iSeries von vorne bis hinten durch, um mal einen Überblick zu bekommen, was man alles mit SQL machen kannst. Auch wenn das Mühsam ist, der Schub für die Programmentwicklung ist enorm...

Viel Spass...
Martin Withake