DDS --> SQL

[UFK]

Vom prinzipiellen Standpunkt aus möchte ich das Umstellen auf SQL auch befürworten, warne aber davor, alles für ganz einfach zu halten.

Ich hatte z.B. mal Anwendungen zu tun, die auf (zu) komplex definierten LF's beruhten, die als Joins z.B. auf 12-15 PF's mit einer Dynamic_Selection basierten. Da die ganze DB so gestrickt war, gab es bei manchen Dateien dann über 30 mögliche Zugriffswege. Unter V5R2 oder VR3 kapitulierte die SQL-Engine bei der Optimierung des Zugriffs, und beschloss in der Regel, die Daten über die Monster-LF's zu scannen - mit katastrophalen Laufzeiten (1-5 Min pro Transaktion).

Ich konnte durch Umformulierung auf SQL hingegen Laufzeiten von 1-3 Sek bekommen, was für sehr komplexe Abfragen durchaus angemessen erschien.

Allerdings haben wir unsere Anwendungen nicht kurzfristig umschreiben können, um mit diesen dynamisch gebildeten SQL's zu arbeiten. Ich konnte zwar ein Konzept dafür liefern, aber selbst innerhalb eines Jahres fanden die Programmierer keine Zeit zur Realisierung meiner Pläne.

In manchen Fällen wird es eher so sein, dass man lieber die ganze Anwendung neu designen und programmieren sollte, als sich zu lange durch Altlasten fesseln zu lassen.

[Pikachu]

Falls eure RPG-Programmem mit Satzformatnamen arbeiten: Wie legt ihr diese Satzformatnamen in SQL fest?

[Fuerchau]

CREATE TABLE .... RCDFTM 'FORMATNAME'

Da eine LF, die mit CREATE INDEX erstellt wurde, auch per Native-IO in RPG gelesen werden kann, muss hier der Formatname per RENAME im RPG festgelegt werden.

[loeweadolf]

Was ist denn eigentlich der entscheidende Vorteil, wenn DDS-Dateien geändert werden in SQL-Tabellen ?

Bei Zugriff aus RPG-Programmen vermutlich kein Vorteil ??

Bei Zugriff über Embedded SQL ? evtl. bessere Zugriffszeit ?

In DDS-Quellen sind Dateien nach meiner Meinung zuindest besser zu dokumentieren.

[BenderD]

Performance Unterschiede im realen Betrieb alle unter der Messbarkeitsgrenze.
Schritt in Richtung Standardisierung ist wohl das Ausschlag gebende, bleibt allerdings ohne Umorientierung weg von RLA ohne Wirkung.
Insgesamt ist Programmierung mit SQL statt mit RLA vom Gesichtspunkt Aufwand und Leistung (Transaktionssicherheit etc.) im Vorteil, da SQL mehr Möglichkeiten bietet.
Wenn man die Vorteile wirklich zum tragen bringen will, brauchts da einen Umdenkungsprozess, reine Kosmetik hilft da nix und schadet oft!

D*B

Was ist denn eigentlich der entscheidende Vorteil, wenn DDS-Dateien geändert werden in SQL-Tabellen ?

Bei Zugriff aus RPG-Programmen vermutlich kein Vorteil ??

Bei Zugriff über Embedded SQL ? evtl. bessere Zugriffszeit ?

In DDS-Quellen sind Dateien nach meiner Meinung zuindest besser zu dokumentieren.

[RobertPic]

Was ist denn eigentlich der entscheidende Vorteil, wenn DDS-Dateien geändert werden in SQL-Tabellen ?

[+]
Naja, im "Optimalfall" (alles über SQL) hat man keine Sorgen mehr mit dem Levelcheck und ist wesentlich flexibler bei Dateiänderungen.

[+]
Die Problematik verwendet die neue SQL-Engine meine alten DDS-Zugriffswege - entfällt.

[+]
Joins und where-Conditions sind DDS-Joindateien nicht gerade der Hit (Felder anführen, nicht so mächtig wie SQL).

[+]
Zu überlesende Sätze (laut Parameter) werden mit SQL schneller überlesen.

[+/-]
Optimiert wird nur nich die SQL-DB-Engine! Minus deshalb, da nicht alle hier von der neuen Engine überzeugt sind...

ABER:
[-]
Bei Einzel-Lesenoperationen ist SQL mMn langsamer.

[--]
Statt einer Zeile für eine Dateioperationen werden es viele Zeile (SQL-Statement). In Summe hat man dann größere Programme.

Datenbanklastige Applikationen mit purem SQL will sich eigentlich keiner antun - egal in der welcher Programmiersprache. Je nach Entwicklungsumgebung gibt es da verschiedene Erleichterungsmöglichkeiten (OO, Persitenzframeworks, GUI-Componenten mit Databinding...) - in RPG/Cobol gibt da allerdings keine.

Wie Dieters schon angesprochen hat: Es kommt auf das Gesamtkonzept an. Eine 3GL-Anwendung auf SQL umzustellen, macht zwar etwas flexibler, wird mit viel SQL-Code erkauft.

Ich würde das eher für den "letzten Rest 3GL" in Betracht ziehen (z.B. ein Preisfindungsmodul), aber nicht als alleiniges Rezept zur Modernisierung verstehen.

/Robert

[BenderD]

im wesentlichen mit den Kernpunkten einverstanden.
Aber im Vergleich RPG/Cobol mit Index sequentiellem Zugriff versus embedded SQL in RPG/COBOL (und darum gings in der Frage) würde ich das ein wenig anders akzentuieren:
- ISAM mit RLA braucht weniger Ressourcen (mit Hardware überkompensierbar!)
- Mengen orientierter Zugriff per SQL (alles in ein SQL Statement oder View packen, dann sequentiell über den Cursor!) schlägt ISAM per RLA in jeder Hinsicht um Längen!
- bei Java etc. bin ich wieder bei Dir, da kann man weit über SQL hinausgehen und befindet sich dann bereits "Jenseits von SQL" (s o habe ich mal einen Vortrag zu diesem Thema genannt).

D*B

ABER:
[-]
Bei Einzel-Lesenoperationen ist SQL mMn langsamer.

[--]
Statt einer Zeile für eine Dateioperationen werden es viele Zeile (SQL-Statement). In Summe hat man dann größere Programme.

Datenbanklastige Applikationen mit purem SQL will sich eigentlich keiner antun - egal in der welcher Programmiersprache. Je nach Entwicklungsumgebung gibt es da verschiedene Erleichterungsmöglichkeiten (OO, Persitenzframeworks, GUI-Componenten mit Databinding...) - in RPG/Cobol gibt da allerdings keine.

/Robert

[RobertPic]

Aber im Vergleich RPG/Cobol mit Index sequentiellem Zugriff versus embedded SQL in RPG/COBOL (und darum gings in der Frage) würde ich das ein wenig anders akzentuieren:

Ja, das habe ich etwas zu "stark vereinfacht" bzw. zu ungenau. Mit Einzelread meinte ich wirklich nur eine Leseoperation (keine Sequence), also z.B. die Bankbezeichnung aufgrund einer Bankleitzahl dazulesen. Die im SQL zu verhinderten n+1 Reads sind mit RPG/Cobol weniger dramtisch.

Aber sobald es um mehrer Daten geht (eben auch einzeln per cursor) hat man mit SQL die Nase vorn.

Noch ein Nachtrag zu SQL:
Mit zunehmender Normalisierung der Datenbanken wird der konventionelle (RPG/Cobol, pures SQL) Weg auch immer mühsamer, da immer mehr Joins für das gleiche Ergebnis notwendig sind (im Vergleich zu weniger normalisierten Daten).

/Robert

[Fuerchau]

Da gibts dann immer noch FETCH 1 ROW ONLY oder, wenn der Schlüssel (durch Integrität) tatsächlich eindeutig ist, kann ich mir den Cursor sparen und einen SELECT INTO verwenden, und der ist auch nicht langsamer als ein CHAIN/READ INVALID.

[BenderD]

genau dieser Einzelzugriff ist aber nicht SQL like, der gehört per Join (besser noch per View) in einen Join im Cursor rein. Die ganze Normalisierung gehört im View Layer (soweit möglich) wieder denormalisiert!
Die Grenze findet das erst im Update (deshalb Datenbankzugriffsmodule, die das dann wieder auflösen) und bei verzweigten Objektbäumen, die sich nicht immer als flache Relation darstellen lassen.

D*B

Mit Einzelread meinte ich wirklich nur eine Leseoperation (keine Sequence), also z.B. die Bankbezeichnung aufgrund einer Bankleitzahl dazulesen.
/Robert

[loeweadolf]

Wenn jemand seine Anwendungen (RPG) nicht grundlegend überarbeiten will, dann kann ich aus den Antworten auf meine Fragestellung (DDS/SQL) keinen Grund erkennen, warum die Tabellen von DDS auf SQL umgestellt werden solten.

Auch ohne Umstellung können DDS-Dateien ja auch bei Bedarf mit SQL bearbeitet werden.

[BenderD]

... ich fühle mich da durchaus richtig interpretiert. Ich würde aber vehement empfehlen alles, was man neu macht, nach neuem Standard zu entwickeln. Sprich: weg von RLA und DDS zu SQL. Sobald man sich in der neuen Denke heimisch fühlt, wird man auch einiges, was man ändert umstellen und alles was Läuft, das läuft: never run a achanging system.

D*B

Wenn jemand seine Anwendungen (RPG) nicht grundlegend überarbeiten will, dann kann ich aus den Antworten auf meine Fragestellung (DDS/SQL) keinen Grund erkennen, warum die Tabellen von DDS auf SQL umgestellt werden solten.

Auch ohne Umstellung können DDS-Dateien ja auch bei Bedarf mit SQL bearbeitet werden.