Hallo,

der Hauptgrund warum man SQL Tabellen verwenden sollte ist der, dass in SQL-Tabellen (z.B. in gepackte numerische Felder) kein Schrott eingefügt werden kann. Selbst bei einem CPYF mit *NOCHK können keine ungültige Daten in die Datei geschrieben werden.

Intern in SQL Tabellen wird immer beim Reinschreiben auf gültige Daten geprüft, während bei DDS beschriebenen Dateien immer erst beim Lesen geprüft wird. Wenn man sich das Verhältnus von Lese zu Schreib-Operationen überlegt und dann im Hinterkopf behält, dass eine Prüfung der Daten wenn auch nur minimal Zeit kostet, kann man sich vorstellen, dass die Verarbeitung mit SQL-Tabellen performanter wird (im Vergleich zu DDS beschriebenen physischen Dateien).

Des weiteren wurde die Entwicklung von DDS schon lange "stablilisiert" wie IBM so schön sagt, sprich eingestellt. Seit V5R1 sind alle Neuerungen, in CREATE TABLE nur noch in SQL erfolgt, z.B. das Definieren von Identity Columns, die Verwendung von Large Object-Datentypen, die Erstellung von Zeitspalten, die bei einer Änderung automatisch aktualisiert werden ...

Die Verarbeitung mit embedded SQL hat mehrere Vorteile:
1. auch Programmierer, die kein RPG, COBOL oder JAVA können, sind in der Lage die SQL-Statements zu lesen.
2. Ein großer Teil der Datenbanken-Logik kann in SQL-Views hinterlegt werden. SQL-View haben jedoch keinen Schlüssel und können dafür mit native I/O nur begrenzt eingesetzt werden. Mit embedded SQL wird die Reihenfolge der Datensätze durch eine zusätzliche Order By-Anweisung im Select-Statement vorgegeben.

@Baldur: Wo steht das mit der Blockgröße von 64K versus 4K.

Ich vermute Du meinst die PageSize von SQL Indices, die per Default mit 64K angelegt wird, im Vergleich zu DDS beschriebenen logischen Dateien, die per Default eine PageSize von 8K haben.

Vielleicht noch eine Randbemerkung:
Wenn nur ein einzelner Datensatz gelesen werden muss, ist native I/O immer noch um einiges schneller als SQL. SQL wird dann schnell wenn die Datensätze geblockt verarbeitet werden können.

Birgitta