View Full Version : Umstellung von DDS auf SQL
Hallo,
eine grundsätzliche Frage: könnte man nach Umstellung von DDS auf SQL effizienter und schneller programmieren?
Was mich immer stört ist, dass ich, nachdem ich in DDS ein Feld in eine Datei eingebaut habe, alle Programme wandeln muss, obwohl das Feld dort nicht angesprochen wird. Müsste ich das bei SQL auch noch tun?
Muss ich nach Umstellung auf SQL unbedingt alle Programme auf Embedded-SQL umstellen, oder laufen die alten Programme weiter?
Welche Lizenzprogramme werden wür Umstellung auf SQL benötigt? Und welche Lizenzprogramme benötigt man für Embedded-SQL?
Fragen über Fragen, ich hoffe, ihr könnt mir helfen.
Gruß
Artur
Hallo,
nur ein paar Überlegungen:
- mit embedded SQL ist man flexibler, bei etwas weniger Aufwand (nach Einarbeitung)
- die Wandel Arie muss auch bei RLA nicht sein, wenn man die alte LF belässt und eine weitere anlegt; bei embedded SQL wird Feld weise zugegriffen
- benötigt wird zum Programm erstellen das SQL Development Kit, dass auch alle Compiler für embedded SQL beinhaltet, zur Ausführung braucht man nix zusätzliches.
mfg
Dieter Bender
Hallo,
eine grundsätzliche Frage: könnte man nach Umstellung von DDS auf SQL effizienter und schneller programmieren?
Was mich immer stört ist, dass ich, nachdem ich in DDS ein Feld in eine Datei eingebaut habe, alle Programme wandeln muss, obwohl das Feld dort nicht angesprochen wird. Müsste ich das bei SQL auch noch tun?
Muss ich nach Umstellung auf SQL unbedingt alle Programme auf Embedded-SQL umstellen, oder laufen die alten Programme weiter?
Welche Lizenzprogramme werden wür Umstellung auf SQL benötigt? Und welche Lizenzprogramme benötigt man für Embedded-SQL?
Fragen über Fragen, ich hoffe, ihr könnt mir helfen.
Gruß
Artur
Unsere Felder sind in Physischen Dateien definiert. Die logischen Dateien nutzen wir nur für die Schlüsselfelder. Somit wandle ich die physischen und die logischen Dateien neu.
Gruß
Artur
Hallo,
nur ein paar Überlegungen:
- mit embedded SQL ist man flexibler, bei etwas weniger Aufwand (nach Einarbeitung)
- die Wandel Arie muss auch bei RLA nicht sein, wenn man die alte LF belässt und eine weitere anlegt; bei embedded SQL wird Feld weise zugegriffen
- benötigt wird zum Programm erstellen das SQL Development Kit, dass auch alle Compiler für embedded SQL beinhaltet, zur Ausführung braucht man nix zusätzliches.
mfg
Dieter Bender
Über eins sollte man sich im Klaren sein:
Bei SQL ist mehr Definitions und Tiparbeit gefragt, wenn man's denn richtig machen will.
Dateien, die per CREATE TABLE erstellt werden, erhalten als Formatnamen den Namen der Tabelle.
Man sollte nie "SELECT *" verwenden, da sonst eben wieder mehrfach umgewandelt werden muss (Tiparbeit).
Normalerweise sperrt ein SELECT nie !!!
Also Vorsicht bei UPDATE (neues Konzept) !
Um Sperren beim SELECT zu erhalten, hilft nur Journaling und CMTLVL(*ALL), was allerdings immer noch nicht das Lesen durch andere Programme verhindert.
Neue Daten können nur per INSERT erstellt werden, auch hier ist Tiparbeit wieder gefragt.
Da beim INSERT jedoch nicht immer alle Felder benannt werden müssen, ist beim CREATE TABLE über NULL-Werte bzw. Defaults nachzudenken, ggf. sind Trigger nötig.
Häufig werden für laufende Nr'n einfach CHAIN/ADD 1/UPDAT kodiert, das funktioniert so nicht mehr sicher.
Hier sind ggf. Generatoren nötig bzw. eben neue Konzepte.
Es gibt da sicherlich noch viele weitere Punkte, jedoch ist eins sicher:
SQL erfordert ein Redesign einer Anwendung, da sonst unerwartete Ergebnisse sehr wahrscheinlich werden.
Das hört sich ja nach sehr viel Arbeit an :eek:. Und es muss sehr viel bedacht werden.
Gibt es Tools, die unsere Datenbank auswerten können und dann Vorschläge machen können?
Gruß
Artur
Da helfen auch keine Tools, denn nicht die DB-Analyse ist entscheidend sondern die Anwendungsanalyse.
Wenn z.B. viel mit Satzsperren gearbeitet wird, was ja auch logisch ist, muss man bei SQL eben umdenken.
Sonst gibts jede Menge Chaos durch konkurierende Updates !
Dies ist mit Abstand das größte zu beachtende Problem.
Einspruch euer Ehren, in mehreren Punkten:
ad Formatnamen: der ist für SQL Zugriffe völlig Banane
ad select *: der * wird beim Compile aufgelöst, sprich das läuft bei zusätzlichen Feldern unverändert weiter; bei der nächsten Änderung (sprich recompile) wird das zusätzliche Feld erst sichtbar.
ad Sperren: beim Update nach Cursor sperrt DB2/400 den zuletzt gelesenen Satz auch ohne Commit, das läuft dann ziemlich analog zu Rekord Löffel.
ad Commit Level: bei korrektem Einsatz wird hier vieles möglich, was bei Rekord Löffel Ekzem garnicht geht. Zum Beispiel konsistente Auswertungen während laufender Transaktionen (gerade weil es hier Sperren gegen lesen gibt) - mit Rekord Löffel Ekzem kann man nicht sicher stellen, dass eine Saldenübersicht im Tagesbetrieb ausgeglichenen Saldo liefert.
ad Tipparbeit: bei voller Nutzung von SQL hört das Sätze zusammen klappern (read, setll, reade, Schlüssel besetzen, chain, Schlüssel besetzen chain...) auf und die Tiparbeit nimmt drastisch ab!
ad laufende Nummern: dafür gibt es extra einen Feldtyp mit AUTOINCREMENT, da gibt es im Programm nix zu tippen.
mfg
Dieter Bender,
der in einem völlig übereinstimmt: ohne Umdenken im Anwendungsdesign und ohne solide Kenntnisse wird das eher nix.
Über eins sollte man sich im Klaren sein:
Bei SQL ist mehr Definitions und Tiparbeit gefragt, wenn man's denn richtig machen will.
Dateien, die per CREATE TABLE erstellt werden, erhalten als Formatnamen den Namen der Tabelle.
Man sollte nie "SELECT *" verwenden, da sonst eben wieder mehrfach umgewandelt werden muss (Tiparbeit).
Normalerweise sperrt ein SELECT nie !!!
Also Vorsicht bei UPDATE (neues Konzept) !
Um Sperren beim SELECT zu erhalten, hilft nur Journaling und CMTLVL(*ALL), was allerdings immer noch nicht das Lesen durch andere Programme verhindert.
Neue Daten können nur per INSERT erstellt werden, auch hier ist Tiparbeit wieder gefragt.
Da beim INSERT jedoch nicht immer alle Felder benannt werden müssen, ist beim CREATE TABLE über NULL-Werte bzw. Defaults nachzudenken, ggf. sind Trigger nötig.
Häufig werden für laufende Nr'n einfach CHAIN/ADD 1/UPDAT kodiert, das funktioniert so nicht mehr sicher.
Hier sind ggf. Generatoren nötig bzw. eben neue Konzepte.
Es gibt da sicherlich noch viele weitere Punkte, jedoch ist eins sicher:
SQL erfordert ein Redesign einer Anwendung, da sonst unerwartete Ergebnisse sehr wahrscheinlich werden.
Hallo,
ad Formatnamen:
Formatnamen sind nur für native RPG I/O notwendig. Wenn die bisherigen Anwendungen nach Konvertierung in SQL beschriebene Dateien ohne Änderung weiterlaufen sollen, müssen die SQL Tabellen einen anderen Formatnamen erhalten.
Um dies zu realisieren gibt es 2 Möglichkeiten:
Vor Release V5R4: Die SQL Tabelle mit dem Formatnamen als Dateiname erstellen (Dateiname=Formatname) und anschliessend mit Rename in den echten Feldnamen umbenennen. Bei der Umbenennung bleibt der Formatname unverändert.
Ab Release V5R4 kann für SQL Tabellen und Views ein abweichender Satz-Formatname über das Schlüsselwort RCDFMT direkt im CREATE TABLE-Statement angegeben werden.
ad laufende Nr.: Laufende Nr. werden über eine Identity Column gesteuert. Pro Tabelle darf genau 1 Identity Column angegeben werden. Bei dieser Spalte muss als numerischer Datentyp definiert sein. Start, Ende, sowie Schrittgröße und die Aktion bei Überlauf können festgelegt werden. Über die Spalte muss ein Unique-Index generiert werden, da die Datei nicht geprüft wird, sondern immer er nächste gecachte Wert verwendet wird. Wird bei Überlauf wieder von vorne angefangen, könnten Duplikate erzeugt werden.
CREATE TABLE MySchema/MyTable
(Id INTEGER GENERATED ALWAYS AS IDENTITY
(START WITH 10 , INCREMENT BY 10),
weitere Felder...)
RcdFmt MyTableF;
Die Identity Column wird beim Schreiben eines neuen Satzes automatisch gefüllt. (auch dann, wenn der Satz über native I/O erstellt wird.)
Wenn es nur darum geht, die DDS beschriebene Tabellen in SQL definierte Tabellen zu verwandeln, kann iSeries Navigator Reverse Engineering verwendet werden.
Im iSeries Navigator Database auf die physische Datei positionieren, Rechts Click und SQL generieren. Aus der DDS beschriebenen Tabelle wird ein SQL Skript erstellt. Schlüsselworte, die von SQL nicht unterstützt werden (z.B. DATFMT, EDITC) werden gekennzeichnet.
Um ein neues Design zu ermöglichen, würde ich die SQL Tabellen mit einem anderen Namen als die ursprüngliche physische Datei erstellen. Anschliessend eine SQL View mit dem Original-Dateinamen, die die Felder in der physischen Datei 1:1 abbildet. Anstatt direkt auf die physische Datei zuzugreifen, die View verwenden.
Über die View können (ab Release V5R4) Instead Of Trigger für Insert, Update und Delete erstellt werden. Der Vorteil von Instead of Triggern ist, dass durch sie verknüpfte SQL-Views upgedatet werden können.
Birgitta
Hallo Artur, nochmals zum DDS: wenn du das neue Feld in deine Datei hinten ran hängst, und deine Datei mit LVLCHK(*NO) umwandelst, brauchst du nicht alle Programme zu wandeln die diese Datei benützen. Ausnahme sind Programme mit embedded SQL, diese solltest du wandeln.
Gruß Dinie.
Gerade embedded SQL benötigt KEINE neue Umwandlung, das ist ja gerade der Vorteil (Ausnahme SELECT * ).
Mit LVLCHK(*NO) müssen auf jeden Fall die Programme gewandelt werden, die einen WRITE haben, da es sonst z.B. zu Dezimalfehlern (falscher DB-Inhalt) beim WRITE kommt.