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