i5 und SQL

[wolfinho]

Hallo zusammen,

wir sind gerade dabei ein neues Datenbank-Modell zu erstellen. Hierbei stellt sich die Frage, wie die Tabellen deklariert werden. Direkt über SQL mit "create table" oder über DDS ? Wird eine der Varianten bevorzugt ?

Desweiteren wollen wir mit COBOL-Programmen auf die Datenbanken zugreifen. Hierzu meine ich in Erinnerung zu haben, daß embedded SQL der Dateiverarbeitung vorzuziehen ist, da bessere Performance. Aber die Datenbanken sind sehr mächtig (viele Spalten) und das Fetch-Statement zu erstellen frisst in solchen Fällen richtig viel Zeit. Desweiteren muss das Fetch-Statement auch immer gepflegt werden, bei Datenbankänderungen. Daher bin ich mir jetzt unsicher geworden, ob es vielleicht doch nicht besser wäre wieder auf die Dateiverarbeitung zurückzukehren.

Was meint Ihr dazu ?

Viele Grüße

[Fuerchau]

Dann hast du SQL nicht verstanden.

CREATE TABLE ist für die spätere Verarbeitung performanter (64K Blockgröße, statt 4K).

In Programmen hat SQL gerade den Vorteil, nur die Daten zu lesen, die man tatsächlich benötigt.
Einzig der Insert kann Probleme bereiten.
Werden allerdings über Trigger oder per CREATE TABLE sinnvolle Defaults eingetragen, benötigt man beim Insert tatsächlich nur die relevanten Felder.

Erst recht gilt dies für den Update, da ich gerade hier nur die zu verändernden Felder angeben muss.

Eine Compilierung oder gar Anpassung bestehender Programme ist nicht erforderlich.
Neue Felder werden eben nur von den neuen/geänderten Programmen verwendet. Alle anderen interressiert das nicht.

Bei DDS musst du tatsächlich alle betroffenen Programme wandeln.

[wolfinho]

vielen dank für die Antwort.
das mit der 64k-Blockgröße wusste ich tatsächlich nicht.

Bei der Nutzung von embedded SQL in Cobol-Programmen habe ich vergessen zu erwähnen, daß wir bei uns auf der i5 einen Delta-Bestand in einen Gesamtbestand einspielen wollen. Hierzu habe ich einen Cursor mit "Select *" definiert. Also muss ich doch bei Tabellenänderungen auch jeweils das Fetch-Statement anpassen, da sonst die Anzahl der Tabellenspalten nicht mehr zu der Anzahl der Hostvariablen passt.
Die Tabellen des Delta-Bestandes und des Gesamt-Bestandes haben einen identischen Aufbau.
Aber mit embedded SQL bin ich hier wahrscheinlich auf einem falschen Weg, oder ?

[Fuerchau]

Wenn du die Daten nur von rechts nach links kopierst, kannst du auch einen

insert into fileb
select * from filea

codieren.
Desweiteren erlaubt der "Fetch into" auch als Ziel eine Struktur.
COPY-DDR funktioniert auch auf SQL-Tables, so dass du hier nicht alles explizit definieren musst.

Für reine Kopierarien reicht
CPYF
QM-Query mit obigem Insert...Select.

[B.Hauser]

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

[Fuerchau]

Das mit der Prüfung beim Lesen von DDS-Dateien halte ich auch für ein Gerücht!

Sowohl beim Schreiben als auch beim Lesen erfolgt KEINE Prüfung durch die Datenbank.
Die Leseprüfung erfolgt durch den internen RPG-Overhead, der aus dem Dateipuffer in die Variablen überträgt und dabei eben Dezimalfeldfehler auslöst.
Diese Prüfung kann ich aber mittels
CRTRPGPGM IGNDECERR(*YES)
ausschalten. Fehlerhafte Dezimaldaten werden dann zu 0 übersetzt.
Im ILERPG gibts sogar eine H-Bestimmung dazu.

Bei COBOL sieht das da nämlich ganz anders aus. COBOL arbeitet direkt mit den Dateipuffern und bekommt daher auch beim Lesen keine Fehler.
Erst beim Ansprechen der Variableninhalte kommt es zum Dezimalfehler.
Eine Compileroption gibts dafür nicht, jedoch kann ich per
IF FELD IS NUMERIC
...
END-IF
Das Problem umgehen.

Da SQL eben noch eine Schicht zwischen der internen PF und dem Programm ist, gibts bem Select ebenso Dezimalfehler bei ungültigen Daten, die ich aber eben nicht ausschalten kann, ebenso prüft SQL VOR der Ausgabe in die PF eben die richtige Typisierung.

[B.Hauser]

Das mit der Prüfung beim Lesen von DDS-Dateien halte ich auch für ein Gerücht!

Dann würde ich Dir den folgenden Artikel empfehlen:
Modernizing Database Access
The Madness Behind the Methods
By Dan Cruikshank

Birgitta

[BenderD]

für create table spricht:
- Industriestandard, der im DB2/400 (mitttlerweile) besser unterstützt wird als die (native) Methode DDS
- mehr Möglichkeiten Prüfungen in die Datenbank zu verlagern
- Indexdesign ist (bei Verwendung von SQL zum Zugriff) völlig unabhängig von der Anwendung.

Pflege der fetch Statements:
- identisch zu record level acces, bei richtiger Vorgehensweise sollte maximal ein recompile erforderlich sein (bei rpg externe Datenstruktur und Verwendung select * into :externeDS, sollte cobol auch können ?!)

zur Performance:
- hier werden ganze Artikel über Micro Sekunden und Millisekunden geschrieben, das ist alles Banane (in Worten: a l l e s B a n a n e !!!)
- Voraussetzung für flotte SQL Zugriffe ist ein passendes Index Design! erforderliche Zugriffspfade müssen halt da sein, sonst gehts auf die Dörfer!
- vorteilhaft sind bei SQL Mengen orientierte Zugriffe (Cursor statt select into, blocken, wenn möglich, join Operationen statt Daten zusammen klappern)
- bei obigen Voraussetzungen kann SQL durch pre fetching (asynchronous database i/o stattt synchronous), was rla nur bei sequentieller Verarbeitung kann, Vorteile herausholen.
- bei den genannten Voraussetzungen kann SQL mehr CPU nutzen und in Geschwindigkeit umsetzen als RLA, braucht allerdings auch etwas mehr (Daumen: 10%), um gleich schnell zu sein.
- den größten Performance Vorteil hat SQL bei der Programmierer Performance und da umso mehr je konsequenter man die Vorteile nutzt und je weniger man sich mit Randeffekten beschäftigt (wer prüft wann was, wann und wie wandert der open ins Klo, warum kommt Evi nicht und solchen Kram).
- Unterstützung liefert SQL auch für das Schreiben von stabilen Anwendungen durch umfassendere Prüfungen zur Compile Zeit (das ist der Hauptaspekt der Prüfungen!!!) und durch enge Typprüfung, sowie durch einfacheren Einsatz von Commit Steuerung (was allerdings gerade bei SQL unbedingtes Muss ist)

D*B

Hallo zusammen,

wir sind gerade dabei ein neues Datenbank-Modell zu erstellen. Hierbei stellt sich die Frage, wie die Tabellen deklariert werden. Direkt über SQL mit "create table" oder über DDS ? Wird eine der Varianten bevorzugt ?

Desweiteren wollen wir mit COBOL-Programmen auf die Datenbanken zugreifen. Hierzu meine ich in Erinnerung zu haben, daß embedded SQL der Dateiverarbeitung vorzuziehen ist, da bessere Performance. Aber die Datenbanken sind sehr mächtig (viele Spalten) und das Fetch-Statement zu erstellen frisst in solchen Fällen richtig viel Zeit. Desweiteren muss das Fetch-Statement auch immer gepflegt werden, bei Datenbankänderungen. Daher bin ich mir jetzt unsicher geworden, ob es vielleicht doch nicht besser wäre wieder auf die Dateiverarbeitung zurückzukehren.

Was meint Ihr dazu ?

Viele Grüße

[Fuerchau]

@Birgitta
Bei DDS-Dateien erfolgt in COBOL mit Native-IO auch keine Prüfung auf ungültige Inhalte!
Die Schrottdaten die ich geschrieben habe bekomme ich beim Lesen genauso zurück.

Bei SQL-Tables darf ich auch in COBOL keine ungültigen Daten schreiben, das ist korrekt.
Der Unterschied zwischen COBOL und RPG ist i.W. der, dass COBOL mit den originären Dateipuffern arbeitet, währen RPG zusätzliche Moves von/zum Puffer einbaut.

Betrachte ich nun die Validierungsebenen so erhalte ich in RPG mehr als in COBOL.
RPG Lesen:
Chain/Read in internen Puffer ohne Validierung
Übertragung in Programmvariablen mit Validierung
RPG Schreiben:
Übertragung Programmvariablen in Dateipuffer mit Validierung
WRITE/UPDATE in internen Puffer ohne Validierung

COBOL Lesen:
Read in internen Puffer ohne Validierung
Eine Übertragung in Programmvariablen erfolgt erst gar nicht
COBOL Schreiben:
Eine Übertragung aus Programmvariablen erfolgt erst gar nicht
Write aus internem Puffer ohne Validierung

Bei embedded SQL habe ich sowohl in RPG als auch in COBOL grundsätzlich eine automatische Validierung, da die SQL's ja in Call's und Moves aufgelöst werden.
D.h., dass der Precompiler zusätzliche Variablen entsprechend der SQL-Definition generiert und beim Select/Fetch aus diesen in die Hostvariablen überträgt und eben beim Insert/Update aus den Host- wieder in die automatischen Variablen.
Neben der Validierung durch SQL selber erfolgt ja auch bei diesen Moves quasi schon eine Validierung, die eben durch die SQL-Schicht noch mal durchgeführt wird.

(Für jeden Move/Eval wird ja en MI-Befehl generiert und Dezimalbefehle prüfen generell auf gültige Feldinhalte, die ich aber mit IGNDECERR ausschalten kann).

Es gibt bei COBOL mit SQL keinen Geschwindigkeitsvorteil mehr gegenüber RPG mit SQL, da ja nun in beiden Fällen mit zusätzlichen Moves gearbeitet wird.

[B.Hauser]

@Baldur:

Ich habe nie davon geredet, dass RPG oder Cobol oder (embedded) SQL beim Lesen oder Schreiben prüfen oder nicht prüfen!

Ich habe davon geredet, dass beim Schreiben in SQL Tabellen (direkt in den Tabellen) geprüft wird, ob gültige Daten ankommen oder nicht! Dabei ist es völlig unerheblich, wie dieses Schreiben erfolgt, d.h. selbst bei einem CPYF mit *NOCHK in eine SQL-Datei können keine ungültigen Werte in die Datei geschrieben werden.

Für jeden Move/Eval wird ja en MI-Befehl generiert und Dezimalbefehle prüfen generell auf gültige Feldinhalte, die ich aber mit IGNDECERR ausschalten kann

... und auch dann wirst Du keine ungültige gepackte numerische Daten in eine SQL Tabelle bekommen!

Beim Schreiben in DDS beschriebene Dateien erfolgt diese Prüfung nicht, d.h. mit einem CPYF und *NOCHK kann jeder Schrott in eine DDS beschriebene Datei kopiert werden.

Beim Lesen aus einer SQL-Tabelle erfolgt (innerhalb der Tabelle) keine Prüfung, während beim Lesen aus DDS beschriebenen Tabellen (bevor die Informationen bei RPG oder COBOL ankommen) geprüft wird, ob in den Feldern gültige Daten stehen. Was RPG und COBOL mit diesen Informationen machen, steht auf einem anderen Blatt!

Diese Prüfung beim Schreiben und beim Lesen erfolgt in der Tabelle bzw. in der physichen Datei und hat mit der Prüfung, die durch RPG, COBOL oder embedded oder interaktiven oder ODBC oder JDBC-Zugriff nichts aber auch überhaupt nichts zu tun!

.... und genau das steht auch in dem Artikel!!!

Wenn Du den Artikel genau gelesen hättest, hättest Du auch festgestellt, dass lediglich die physischen Dateien durch SQL-Tabellen und geschlüsselte logische Dateien durch SQL Indices ersetzt wurden (bzw. nach dem Erstellen der Indices die DDS beschriebenen logischen Dateien neu generiert wurden).

Das Programm, mit dem getestet wurde hat jeweils nur native I/O verwendet. Es erfolgte keine Konvertierung des Source-Codes in embedded SQL.

Birgitta

[Fuerchau]

Und warum bekomme ich den geschrieben Schrott denn beim Lesen wieder zurück ?
Wenn eine Prüfung erfolgen würde, müsste ich ja einen Fehler beim Read bekommen.
Die schrottigen Daten stehen aber im Puffer.
Was macht die Prüfung denn dann für einen Sinn ?

[BenderD]

Glaube keiner Benchmark, die du nicht selber gefälscht hast.

aktuelle Hardware sollte eine einzelne I/O Operation im Bereich 1 Milli Sekunde (10 ** -6) bewerkstelligen.

auf aktueller Hardware dauert eine CPU Operation in der Größenordnung 0,5 * 10 ** -8 Sec. (entspricht ca. 500 Mips)

das heißt eine I/O Operation dauert solange wie 500 Prozessor Anweisungen. Die oben genannten Zahlen basieren auf Schätzungen und das Verhältnis ist eher größer als kleiner (sprich I/O eher langsamer, CPU eher schneller)

Nun sind an gemessenen Zahlen eine Unsumme an Faktoren beteiligt und wenn ich mal unterstelle, dass das mit der Prüferei alles so stimmt, wobei ich zu Baldur tendiere und mir kaum vorstellen kann, dass Entwickler eines ISAM Dateisystems (entspricht DDS) so blöd sind Tod und Teufel zu prüfen und dann die Ergebnisse zu ignorieren, dann bleibt für mich immer noch klar erkennbar, dass an den Messungen in dem Artikel andere Faktoren beteiligt waren oder die Messung ein Fake ist (wie seinerzeit die Java Benchmark "Towers of Hanoi" die für den CRTJVAPGM sagenhafte Verbesserungen gegenüber ohne aufwies).

Selbst die blanken Messergebnisse legen andere Deutungen nahe, was eine gründliche Untersuchung überprüfen müsste; So ist der CPU Verbrauch in den Charts auf Seite 5 und 6 bei beiden Varianten gleich, die waits sind mehr und der Rest, (der im wesentlichen zu Lasten von I/O geht) nimmt ebenfalls zu. Im Klartext: DDS erstellte wiesen mehr waits und mehr synchronous I/O auf, was sich viel eher aus einem anderem Blockungsverhalten in Verbindung mit pre Fetching und caching erklären lässt.

D*B

Dann würde ich Dir den folgenden Artikel empfehlen:
Modernizing Database Access
The Madness Behind the Methods
By Dan Cruikshank

Birgitta