Warum wird beim CRTLF eine VIEW erstellt, aber kein INDEX???

[ExAzubi]

Hallo zusammen,

vor langer langer Zeit meine ich mich erinnern zu können das eine LF, wenn nur Keyfelder in der Source definiert waren, beim erstellen ein INDEX erstellt wurde.

Habe ich Felder angegeben, oder aber auch gejoint, war es eine VIEW.

Nun aber habe ich unter (V7R2) festgestellt, das eine DDS-Source

R FORMAT       PFILE(FILE)

K FLD1
K FLD2

beim erstellen nur eine VIEW wird, aber kein INDEX, und somit der Performance-Vorteil dann ja dahin ist.

Wenn ich anschließend unter OpsNav hingehe und mir zu der VIEW das SQL generieren lassen möchte, dasnn erscheint auch immer der Hinweis
(SQL1506 Schlüssel oder Attribut für LFile in LIB wurde ignoriert. )

Ist das nur eine Einstellung am System wir er mit der LF umgehen soll, oder aber will IBM jetzt das ich jetzt nur noch SQL mache???

Danke an alle helfenden!

P.S. In der Altanwednung sind eine Menge an LF-DDS vorhanden, die ich ungerne mit CREATE INDEX ersetzen würde... Allerdings will ich aber für meine neuen SQLRPGLE gerne performante Indezes haben....

[B.Hauser]

Dass automatisch Index oder View erzeugt wurde, war nie der Fall. Vielleicht war bei Euch ein Default-Wert anders gesetzt.

Schau Dir den IBM i Navigator (aktuelles Service-Pack) an.
Beim Erstellen/Sichern des Source Codes (über SQL generieren) hast Du die Auswahl (Index anstatt View oder View und zusätzlicher Index). Wenn Du natürlich keine Option setzt wird nur eine View erstellt.
Gleiches gilt für die Stored Procedure GENERATE_SQL. Hier gibt es die Parameter ADDITIONAL_INDEX_OPTION und INDEX_INSTEAD_OF_VIEW_OPTION

... und IBM will dass Du nur noch SQL machst! Weil DDS bereits seit Release V5R3 stabilisiert ist und nicht mehr weiterentwickelt wird. Dass Du allerdings alle Zugriffe mit embedded SQL machst ist nicht erforderlich. SQL Indices können in native I/O genau wie geschlüsselte logische Dateien verwendet werden und sind zudem noch um einiges mächtiger.
Hier ein Artikel dazu: SQL indexes and native I/O – no contradiction

Was spricht übrigens dagegen DDS-LF durch Indices zu ersetzten?
Du kannst natürlich beides verwenden, DDS-LF und Indices, solltest aber die LFs, nachdem Du die Indices erstellt hast ebenfalls neu erstellen (damit Du nur einen Zugriffs-Weg / Access Path) hast.
Die Programme brauchst Du, auch dann wenn Du von DDS nach SQL-Indices konvertiert hast eigentlich noch nicht einmal umzuwandeln (obwohl ich das empfehlen würde)

Birgitta

[Pikachu]

Woran siehst du das? Was zeigt ein DSPFD FILE(Logische Datei) TYPE(*ACCPTH) ?

... beim erstellen nur eine VIEW wird, aber kein INDEX ...

[ExAzubi]

Hallo Brigitta,

danke für die Antwort.
Ich denke auch das für embeddedSQL innerhalb der RPG-Welt es in der tat keinen Unterschied macht. Uns viel nur auf, das bei einer Web-Anwendung (ODBC mit JavaScript) es einen gewaltigen Performance-Unteschied in der Anwendung gibt, ob die Datei normal gewandelt wurde, oder aber über CREATE INDEX erstellt wurde..


@Pikatchu
Ich sehe das eigentlich nur über den ISeries Navigator. Die ganzen logischen tauchen nur in der Ansicht "Ansichten" auf und nicht bei den Indezes... (Zu finden über System->Datenbanken->DB->Schemata->LIB... )

[Fuerchau]

Das ist SQL-Standard, dass LF's eben als Views auftauchen.
Per nativem DSPFD kann man den Unterschied schon sehen.
Das mit der Performance kann ich nicht direkt nachvollziehen, da es bei der Indexverwendung keinen so großen Unterschied macht. Dazu muss man mal den Indexadvisor bemühen warum der nun eine DDS-LF nicht verwendet, einen SQL-Index dann aber doch.

Mein ganz persönliche Erfahrung mit dem Erstellen/Verwenden von Indizes aus den Optimierungsvorschlägen ist da seit V6R1 eher negativ, da SQL (neu) auch selbst vorgeschlagene Indizes gerne ignoriert.