View Full Version : DDS --> SQL
BurgerKing
27-04-09, 10:43
Hallo,
wir möchten in unserer Anwendung alle Dateien von DDS auf SQL umstellen. Ich stelle mir das folgendermaßen vor. Physische Dateien haben bei uns keine Schlüsselfelder. Daher werden diese zu SQL-TABLE konvertiert. Logische Dateien, die keine Joins, Selects oder Omits haben und nicht auf mehreren physischen Dateien basieren werden zu SQL-INDEX konvertiert.
Logische Dateien, die Joins, Selects oder Omits haben oder auf mehreren physischen Dateien basieren sollen VORERST weiterhin DDS-beschrieben bleiben, damit die guten alten RPG Programme nicht sofort geändet werden müssen.
Jetzt die Frage. Gibt es irgendwo Bedenken - z.B. Performanceprobleme oder anderes - DDS-beschriebene logische Dateien auf SQL-Tables zu legen?
Danke
... man ist halt damit keinen Schritt weiter gekommen und transportiert alle Altlasten in die Neuprogramme (die dann SQL verwenden) mit rüber.
D*B
Hallo,
wir möchten in unserer Anwendung alle Dateien von DDS auf SQL umstellen. Ich stelle mir das folgendermaßen vor. Physische Dateien haben bei uns keine Schlüsselfelder. Daher werden diese zu SQL-TABLE konvertiert. Logische Dateien, die keine Joins, Selects oder Omits haben und nicht auf mehreren physischen Dateien basieren werden zu SQL-INDEX konvertiert.
Logische Dateien, die Joins, Selects oder Omits haben oder auf mehreren physischen Dateien basieren sollen VORERST weiterhin DDS-beschrieben bleiben, damit die guten alten RPG Programme nicht sofort geändet werden müssen.
Jetzt die Frage. Gibt es irgendwo Bedenken - z.B. Performanceprobleme oder anderes - DDS-beschriebene logische Dateien auf SQL-Tables zu legen?
Danke
BurgerKing
27-04-09, 10:58
... man ist halt damit keinen Schritt weiter gekommen und transportiert alle Altlasten in die Neuprogramme (die dann SQL verwenden) mit rüber.
D*B
Die Umstellung soll Schritt für Schritt laufen. Ziel ist eine ausschließlich SQL beschriebene Datenbank mit RPG Programmen, die ausschließlich embedded SQL verwenden. Das geht aber nicht von jetzt auf gleich. Daher auch meine Frage, ob es für den ersten von uns geplanten Schritt bekannte Probleme gibt.
... das ist mir schon klar. Entscheidend ist m.E. (und da unterscheide ich mich durchaus von anderen Kollegen), dass man die erweiterten Möglichkeiten von SQL gegenüber den Indexsequentiellen Zugriffsmethoden von RPG Rekord Löffel auch wirklich konsequent nutzt, sonst lässt man es am Besten gleich so wie es ist, das funzt nämlich durchaus auch.
Heißt: in letzter Konsequenz haben alle SQL Tabellen selbstredend primary Keys, sind Indexe Datenbank interne Objekte, die Programme nicht kennen, greifen alle Programme ausschließlich über Views zu, nutzt man referentielle Integrität und Transaktionssicherheit durch Commit Steuerung. Die Datenbank Zugriffsschicht ist von Geschäftslogik und Benutzerbedienung separiert und die Datenbank ist sauber normalisiert.
Ein Wechse der Sprache bei der Datenbankerstellung von DDS nach SQL hat dabei weder nennenswerte Wirkungen, noch lässt er nennenswerte Nebenwirkungen befürchten (da gibt es ein paar technische Details, diese sind allerdings ohne messbare Relevanz).
Als wichtiger und vordringlicher sehe ich da Änderungen in der Struktur und Leistung der Datenbank (primary Key, referential Integrity...) und Prüfung der Anwendung auf Schichtentrennung, Verbesserungen in diesem Bereich und Umstellung von RLA nach SQL Zugriffen.
D*B
Die Umstellung soll Schritt für Schritt laufen. Ziel ist eine ausschließlich SQL beschriebene Datenbank mit RPG Programmen, die ausschließlich embedded SQL verwenden. Das geht aber nicht von jetzt auf gleich. Daher auch meine Frage, ob es für den ersten von uns geplanten Schritt bekannte Probleme gibt.
LF's mit eigenen Join/Select's dürften auf SQL-Tables ggf. nicht funktionieren bzw. erstellbar sein.
Probiert habe ich das bisher nicht da ich dazu keine Veranlassung sah.
Ich denke, du wirst da der erste sein.
Ich hoffe allerdings, dass der CRTLF als Basis keine SQL-Tables akzeptiert. Denn dies würde der SQL-Logik widersprechen.
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.
Falls eure RPG-Programmem mit Satzformatnamen arbeiten: Wie legt ihr diese Satzformatnamen in SQL fest?
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
29-04-09, 12:44
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.
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.