Zugriff über ODBC

[B.Hauser]

Jede LF ohne Select/Omit und Join ist ein Index (Create Index erzeugt eine LF).

Jede logische Datei mit einem Schlüssel (unabhängig davon ob select/omit-Anweisungen und/oder join-Anweisungen angegeben wurden) hat einen Zugriffsweg, der von SQL wie ein Index verwendet werden kann.

Ein Schlüssel in einer physischen Datei wird als primary key constraint gehandelt und ist ebenfalls ein Zugriffsweg, der von SQL verwendet werden kann.

Beim Zugriff auf eine LF verwendet SQL immer die PF, die LF wird nur dann verwendet, wenn deren Index passt und sie eben keine Select/Omit enthält.

Wird eine logische Datei in einem SQL Statement angegeben, muss der Query Optimizer das SQL Statement so umschreiben, dass die physische Datei verwendet wird. Dazu muss das DDS der logischen Datei analysiert und aufgelöst werden. Aus der DDS beschriebenen logischen Datei werden allerdings nur die Feld-Auswahl, die Select/Omit-Anweisungen und die Join-Informationen entnommen und aufgelöst. Die Key Informationen bleiben unberücksichtigt.

Bis vor Release 7.1 konnten solche DDS-Analysen nur von der alten/classic Query Engine (CQE) ausgeführt werden und nicht von der neuen SQL Query Engine (SQE). Das Rerouting an die alte Query Engine kann zwischen 10 und 15% Performance kosten.

Die eigentliche Optimierung, d.h. ob und welcher Zugriffsweg verwendet wird erfolgt erst nach dem Umschreiben des SQL-Statements. Zu diesem Zeitpunkt weiß der Optimizer nicht mehr, dass ursprünglich eine logische Datei mit irgendwelchen Schlüssel-Feldern angegeben war, d.h. es werden ALLE Zugriffswege analysiert und bewertet.

Deshalb NIEMALS eine DDS-beschriebene logische Datei in einem SQL-Statement angeben.

Für eine perfomante Verarbeitung von SQL Statements sind die richtigen Zugriffswege (geschlüsselte logische Dateien oder SQL Indices) unbedingt erforderlich. Im Gegensatz zu einer logischen Datei kan ein SQL Index nicht in einem SQL-Statement angegeben werden.

Birgitta