@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



Zitat Zitat von B.Hauser Beitrag anzeigen
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