[NEWSboard IBMi Forum]
Seite 1 von 3 1 2 ... Letzte

Thema: DDS --> SQL

  1. #1
    Registriert seit
    May 2007
    Beiträge
    8

    DDS --> SQL

    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

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... man ist halt damit keinen Schritt weiter gekommen und transportiert alle Altlasten in die Neuprogramme (die dann SQL verwenden) mit rüber.

    D*B

    Zitat Zitat von BurgerKing Beitrag anzeigen
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #3
    Registriert seit
    May 2007
    Beiträge
    8
    Zitat Zitat von BenderD Beitrag anzeigen
    ... 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.

  4. #4
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... 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

    Zitat Zitat von BurgerKing Beitrag anzeigen
    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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  5. #5
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  6. #6
    Registriert seit
    Apr 2005
    Beiträge
    104
    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.

  7. #7
    Registriert seit
    Nov 2003
    Beiträge
    2.304
    Falls eure RPG-Programmem mit Satzformatnamen arbeiten: Wie legt ihr diese Satzformatnamen in SQL fest?

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Jul 2003
    Beiträge
    331

    Cool

    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.

  10. #10
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    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

    Zitat Zitat von loeweadolf Beitrag anzeigen
    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.
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  11. #11
    Registriert seit
    Oct 2004
    Beiträge
    240
    Zitat Zitat von loeweadolf Beitrag anzeigen
    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

  12. #12
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    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

    Zitat Zitat von RobertPic Beitrag anzeigen
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

Similar Threads

  1. Umstellung von DDS auf SQL
    By bie-dro in forum NEWSboard Programmierung
    Antworten: 14
    Letzter Beitrag: 14-09-07, 15:17
  2. Befehl zum Konvertieren DDS in SQL
    By deni87991 in forum IBM i Hauptforum
    Antworten: 6
    Letzter Beitrag: 31-08-06, 13:05
  3. SQL -> CREATE VIEW
    By Kaufmann in forum IBM i Hauptforum
    Antworten: 17
    Letzter Beitrag: 11-05-06, 15:57
  4. QUERY --> SQL
    By redsky in forum NEWSboard Programmierung
    Antworten: 1
    Letzter Beitrag: 17-10-05, 12:23
  5. MS Sql Server + iSeries -> Verbindungsserver
    By reraru in forum NEWSboard Programmierung
    Antworten: 13
    Letzter Beitrag: 20-04-05, 14:07

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •