View Full Version : DDS --> SQL
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
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
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
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.
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
30-04-09, 20:04
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.
... 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.
BenderD
genau dieser Einzelzugriff ist aber nicht SQL like, der gehört per Join (besser noch per View) in einen Join im Cursor rein.
Ja das ist schon klar wie man das mit SQL macht. Ist eigentlich noch ein Grund gegen eine Umstellung. Für die optimale Performance genügt es nicht einfach die Dateioperationen 1:1 umzusetzen, sondern mehrere READ's per Join zusammenzufassen.
Fuerchau
und einen SELECT INTO verwenden, und der ist auch nicht langsamer als ein CHAIN/READ INVALID.
Mein Eindruck wahr eher "gefühlt" als gemeesen (drum auch mMn). Die n+1 Problematik dürfte wohl eher bei JDBC/ODBC (wg. Netzerkoverhead) zum Problem werden.
Was noch bleibt, ist, dass bei SQL die Felder noch gemappt werden müssen. Zumindest in Cobol gibt es kein Mapping, da wird der ganze Record verschoben (auch wenn's Müll ist).
@loeweadolf
Ein paar Vorteile (Datei ändern ohne Levelcheck, gleiche Indexe für RPG und SQL) gibt es schon - aber keiner rechtfertigt (für sich alleine) eine Umstellung.
/Robert
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.
Ich würde empfehlen den folgenden Artikel von Dan Cruikshank zu lesen:
Modernizing Database Access
The Madness Behind the Methods (http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performance_DDS_SQL.pdf )
Ein anderer Grund warum man sich langsam aber sicher von DDS verabschieden sollte ist, das DDS seit Release V4R5 "stabilisiert" ist. Sämtliche Neuerungen sind seither nur noch in die SQL DDL (Data Definition Language) eingeflossen, z.B. Identity Columns (V5R1), neue Datentypen (LOBs, DecFloat, RowId), Hidden Columns und automatische Aktualisierung von Zeitmarken-Feldern, bei Änderung des Datensatzes (6.1) ...
Auf alle Fälle sollte man, bei Umstellung auf SQL eine separate Spalte mit einem eindeutigen künstlichen Schlüssel (ob dieser als Identity Column definiert oder andersweitig ermittelt wird, sei dahingestellt) hinzufügen und diesen Schlüssel als Primary Key definieren. Dadurch können auf alle Fälle Zugriffe über die relative Satz-Nr. vermieden werden und auch bei Tabellen, bei denen kein eindeutiger Schlüssel definiert werden kann (z.B. Bewegungsdateien) schnell und direkt zugegriffen werden. (Beim Zugriff über die relative Satz-Nr. über SQL wird in der CQE immer ein Table Scan ausgeführt, bei Zugriff über die SQE eine Table Probe, was zwar gegenüber dem Table Scan schneller ist, aber lange nicht optimal ist.)
Ab 6.1 sind DDS beschriebenen logische Dateien nur noch bei geschlüsselten Join-Files, auf die über Native I/O zugegriffen werden muss, notwendig. Alles andere, sprich Feldselektion bzw. Erstellung von zusätzlichen Spalten, Select/Omit-Anweisungen und Schlüssel-Definition (auch über die zusätzlichen Spalten) kann über einen SQL-Index abgedeckt werden. Übrigens, von diesen Neuerungen in 6.1 kann bislang fast nur der native I/O profitieren, SQL-Abfragen können bis dato diese neuen Indices noch nicht optimal nutzen.
Was die Verwendung von komplexen logischen Dateien in Verbindugn mit "dynamischem" SQL angeht:
Der Query-Optimizer (unabhängig davon, ob das SQL-Statement dynamisch oder statisch gebildet wird) über geht logische Dateien, die mit DYNSLT oder mit Access Path Maintenance *REBLD definiert wurden. Wird eine solche komplexe logische Datei in einem SQL-Statement angegeben, fackelt der CQE-Optimizer nicht lange und verwendet eine solche Datei, ohne auf die Keys Rücksicht zu nehmen (der SQE-Optimizer kann eh' keine DDS-beschriebenen logischen Dateien verarbeiten.)
Übrigens ab 6.1 kann ein SQL-Index auch einen von der physischen Datei (oder SQL-Tabelle) abweichenden Format-Namen haben.
Birgitta
@Artikel: wenn man den Artikel genauer analysiert, dann fällt auf, dass da read Zeiten von 2 bis 3 milliSec gemessen werden (updates entsprechend länger etc.), das spricht nicht für Produktionsreife Hardware. Ich bleibe dabei: im richtigen Leben ist das unter der Messbarkeitsschwelle!
Der Artikel ist eine Art Preview des dort angeführten Redbooks, das sich mit Modernisierung des Datenbankzugriffs beschäftigt. Beide Quellen sehen dort einen mehrstufigen Prozess vor, der letztlich bei einer Ablösung von DDS und RLA durch SQL DDL und embedded SQL endet. Ich denke, dass sich da eigentlich alle Experten (Birgitta, Robert, Baldur, D*B...) einig sind, dass das von Vorteil ist.
Unterschiedlich eingeschätzt wird die Frage, womit man beginnt, der Artikel und das Redbook sehen da eine 1 zu eins Migration der Tabellen von DDS nach SQL DDL als ersten Schritt (auf dem dann viele hängen bleiben), ich vertrete eher die Position, dass man mit der funktionalen Ebene anfangen sollte, sprich der Herauslösung einer Datenbankzugriffsschicht mit nachfolgender Umstellung von ISAM auf Mengen orientierten Zugriff. Das wesentliche Argument hierfür ist, dass man auf diesem Weg eher Freiheitsgrade für Änderungen am Datenbankaufbau gewinnt und in der mitlleren Perspektive Programmier Aufwand spart (das halte ich für wichtiger als die Einsparung von CPU Sekunden). Technisch gesehen wird diese Vorgehensweise gestützt dadurch, dass SQL besser auf DDS Dateien zugreifen kann, als RLA uf eine reine SQL DDL Welt.
Was die V6R1 Erweiterungen von SQL DDL auf System i (BKA AS/400) angeht, da sehe ich den Weg weg von ANSI SQL zu einem iSQL (BKA SQL/400) eher negativ und rate eher dazu nicht ANSI Features von SQL zu meiden.
D*B
Ich würde empfehlen den folgenden Artikel von Dan Cruikshank zu lesen:
Modernizing Database Access
The Madness Behind the Methods (http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performance_DDS_SQL.pdf )
Ein anderer Grund warum man sich langsam aber sicher von DDS verabschieden sollte ist, das DDS seit Release V4R5 "stabilisiert" ist. Sämtliche Neuerungen sind seither nur noch in die SQL DDL (Data Definition Language) eingeflossen, z.B. Identity Columns (V5R1), neue Datentypen (LOBs, DecFloat, RowId), Hidden Columns und automatische Aktualisierung von Zeitmarken-Feldern, bei Änderung des Datensatzes (6.1) ...
Auf alle Fälle sollte man, bei Umstellung auf SQL eine separate Spalte mit einem eindeutigen künstlichen Schlüssel (ob dieser als Identity Column definiert oder andersweitig ermittelt wird, sei dahingestellt) hinzufügen und diesen Schlüssel als Primary Key definieren. Dadurch können auf alle Fälle Zugriffe über die relative Satz-Nr. vermieden werden und auch bei Tabellen, bei denen kein eindeutiger Schlüssel definiert werden kann (z.B. Bewegungsdateien) schnell und direkt zugegriffen werden. (Beim Zugriff über die relative Satz-Nr. über SQL wird in der CQE immer ein Table Scan ausgeführt, bei Zugriff über die SQE eine Table Probe, was zwar gegenüber dem Table Scan schneller ist, aber lange nicht optimal ist.)
Ab 6.1 sind DDS beschriebenen logische Dateien nur noch bei geschlüsselten Join-Files, auf die über Native I/O zugegriffen werden muss, notwendig. Alles andere, sprich Feldselektion bzw. Erstellung von zusätzlichen Spalten, Select/Omit-Anweisungen und Schlüssel-Definition (auch über die zusätzlichen Spalten) kann über einen SQL-Index abgedeckt werden. Übrigens, von diesen Neuerungen in 6.1 kann bislang fast nur der native I/O profitieren, SQL-Abfragen können bis dato diese neuen Indices noch nicht optimal nutzen.
Was die Verwendung von komplexen logischen Dateien in Verbindugn mit "dynamischem" SQL angeht:
Der Query-Optimizer (unabhängig davon, ob das SQL-Statement dynamisch oder statisch gebildet wird) über geht logische Dateien, die mit DYNSLT oder mit Access Path Maintenance *REBLD definiert wurden. Wird eine solche komplexe logische Datei in einem SQL-Statement angegeben, fackelt der CQE-Optimizer nicht lange und verwendet eine solche Datei, ohne auf die Keys Rücksicht zu nehmen (der SQE-Optimizer kann eh' keine DDS-beschriebenen logischen Dateien verarbeiten.)
Übrigens ab 6.1 kann ein SQL-Index auch einen von der physischen Datei (oder SQL-Tabelle) abweichenden Format-Namen haben.
Birgitta