DDS --> SQL

[B.Hauser]

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

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

[BenderD]

@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

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

[Lucky662]

@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 muss bezüglich ANSI SQL und SQL/400 wiedersprechen.
Jedes Datenbanksystem (OracleDB, MySQL, Microsoft SQL Server, PostgreSQL, DB2, etc) und natürlich auch DB2 for IBM i oder DB2/400 oder auch DB2 z/OS hat so seine Eigenheiten.
Mit ANSI SQL ist der Teil von SQL definiert, der in allen Datenbanksystemen verstanden wird. ANSI SQL macht aber nur Sinn wenn man von der IBM i Abschied nehmen will. Ansonsten ist SQL/400 auf DB2/400 abgestimmt und agiert performanter. Das gleiche gilt übrigens für JAVA-Applikationen. Auch hier gibt es eine JAVA-Version, die auf das System abgestimmt ist.
Was die Umstellung anbelangt, so gehe ich grundsätzlich wie folgt vor:
Ich definiere die alten DDS-Dateien in SQL neu, mit langen, ausführlichen Spaltennamen und dem Systemnamen als alten Feldnamen (column name [alter Feldname]).
Die Tabelle bekommt einen sprechenden langen Tabellennamen und einen klar definierten Systemnamen (10 Stellen). Z.B. XXYYY0000T wobei XX für den Fachbereich steht und YYY nach IBM-Konventionen aus dem Tabellen-Langnamen zusammengestellt wird. Beispiel: Tabellen-Langname automatic_processing würde bei mir, aufgrung der Tatsache, das es sich um eine IT-Interne Tabelle handet mit IT beginnen und dann um APR und 0000 für die alte physische Darstellung (Basistabelle) und T für Tabelle erweitet.
Der Systemname lautet also ITAPR0000T.
In SQL lautet es dann:
create table automatic_processing_0 for system name ITAPR0000T(automatic_processing_ID for column APRID bigint generated by default as identity primary key,
spalten_name1 for column FELD01 char(5) not null default '', .....);
Bei der Vergabe der langen Namen ist darauf zu achten, dass dieser mehr als 10 Stellen aufweist, da man ja einen Systemnamen für die Tabelle selber vergeben und den alten Feldnamen als Spaltennamen setzen will.
Es wird grundsätzlich eine neue ID-Spalte definiert (wenn nicht schon vorhanden), die nichts mit der Fachlichkeit zu tun hat und systemgeneriet wird (generated by default as identity primary key).
Diese ID setze ich i.d.R. als erste Spalte der Tabelle.
Die Übernahme der Daten aus der alten DDS-Datei wird mit einem SQL-Insertstatement erledigt, dass die ID-Spalte weg lässt.
insert into table_name_0(spalten_name1, spalten_name2, ..., letzter_spalten_name) select FELD01, FELD02, ..., FELDXX) from [DDS-DATEINAME];
Durch diesen Insert bekommt jeder Satz eine neue (technische) ID.
Jetzt kann ich die DDS-Datei löschen und die dazugehörige DDS-Beschreibung (PF) in eine Logische wandeln.
Die alte Record-Beschreibung muss dann auf die neue Tabelle mit dem Systemnamen verweisen.

Beispiel:
__________________________________________________ ________________________________
A R RECORD TEXT('Satznamen Beschreibung')
A PFILE(XXYYY0000T)
A FELD01 COLHDG('FELD01')
A FELD02 COLHDG('FELD02')
A DATE01 COLHDG('DATE01')
A TEXT('Datum in *EUR')
A DATFMT(*EUR)
A TIME01 T TIMFMT(*HMS) TIMSEP(':')
__________________________________________________ ________________________________
Hierdurch kann die, bisherige physische Datei im CL/RPG/COBOL wie bisher verwendet werden.
Jetzt müssen noch die logischen Sichten angepasst werden:
__________________________________________________ ________________________________
A UNIQUE
A R RECORD PFILE(XXYYY0000T)
A FORMAT(ALTNAMEP)
A K FELD01
A K FELD02
__________________________________________________ ________________________________

Bevor diese erzeugt werden können muss natürlich die neue logische Sicht, die aus der alten physischen Beschreibung erzeugt wurde, erstellt werden, da die bisherigen Logischen auf diese Satzbeschreibung (FORMAT) verweisen.
Da die Logischen kein Index sind, ist es ratsam die Schlüssel auch für die Erzeugung vom Index zu verwenden, also
create unique index automatic_processing_index_0001 for system name ITAPR0001I on automatic_processing_0(FELD01, FELD02);
Achtet darauf, dass die Angabe unique auch im entsprechenden Index verwendet wird, damit die Definition erhalten bleibt, wenn die Logische gelöscht wird.
Für die Verwendung der Tabele solltet ihr noch eine 1:1 View erzeugen:
create view automatic_processing for system name ITAPR0000V(select * from automatic_processing_0);
Diese View ist die erste Zugriffsdefinition für Select's.
Um die Tabelle in neuen Programmen zu verwenden und ohne großen Aufwand Sätze schreiben zu können definiert ihr noch eine View, die nicht die ID beinhaltet. Auch diese ist, was die Satzauswahl angeht eine 1:1 View.
create view automatic_processing_0001 for system name ITAPR0001V(select spalten_name1, spalten_name2, ..., letzter_spalten_name from automatic_processing_0);
jetzt könnt ihr Insert's tätigen ohne die ID manuell vergeben zu müssen.