Lucky662
26-04-19, 12:10
@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.
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.