View Full Version : Index statt LF-was bedeutet das?
Hallo zusammen!
Vor mir liegen 10 fette IBM Ordner, aber ich finde nicht,was ich suche.
Ich soll bevorzugt mit Index statt mit Logischen arbeiten.
Aber: Was ist Index? Welche Unterschiede gibt es zu LF? Und ist es wirklich sinnvoll? wann verwendet man sowas? Gibt es bestimmte Vor-oder Nachteile? vielleicht sollte ich ja doch ehr LF nehmen?....
bitte helft einer Ahnungslosen
Gruß Kath.
SQL Unterscheidet zwischen INDEX und VIEW. Ein LF ist die "alte" OS/400 Version und kann beides in einem sein. Die SQL-Version hat eine bessere Performance, zumindest beim SQL-Zugriff, da in der Datenbank die Informationen für den Optimizer schon aufbereitet vorliegen. Beim LF müssen diese immer erst gesammelt werden. Beim OS/400 Zugriff (Start, READ, REA-NEXT etc.) ist da kein Unterschied zu spüren.
Ich kann also nur irgendwas mit Index machen, wenn ich eine SQL Table habe?!...
Wie genau geht das dann?
Ich habe eine SQL Tabel verliegen-wie mach ich dann einen Index?
Was ist der Unterschied zw. Index und View? Bisher hab ich nur mit PF und LF gearbeitet und kenn mich nich so tierisch aus...
Was bedeutet das: "da in der Datenbank die Informationen für den Optimizer schon aufbereitet vorliegen. "
Hallo,
mit create table wird eine Tabelle erstellt
mit create index wird ein Index auf eine Tabelle erstellt
mit create view wird eine Sicht auf die Tabelle erstellt
Gruss
Michael
Ein Index mit SQL erstellt "CREATE INDEX ...."
Dadurch wird eine Sortierung der Tabelle nach den in obigem Befehl angegebenen Schlüsselfeldern erreicht. Wenn dann ein "SELECT .... FROM <TABELL> WHERE.... ORDER BY ...
angegeben wird, kann SQL durch die vorsortierte Tabelle schneller auf die Daten zugreifen, muss nicht mehr selber sortieren usw. Für mehr Informationen schau mal ins Handbuch. Will das Ding jetzt nicht abschreiben...
Hallo Kath,
zuerst zu den Gemeinsamkeiten:
Ein Index wird auf der iSeries, wie auch eine DDS beschriebene logische Datei mit dem Object-Attribut LF angelegt.
Ein Index ist ein mit SQL (CREATE INDEX) erstellter Zugriffs-Weg und kann mit einer DDS beschriebenen geschlüsselten logischen Datei ohne Feld-Auswahl, Joins und Select/Omit-Anweisungen verglichen werden.
Ein SQL-Index kann in RPG wie eine logische Datei in den F-Bestimmungen definiert und verarbeitet werden.
Ein SQL Index kann, im Gegensatz zu einer DDS beschriebenen logischen Datei nicht in einem SQL-Statements angegeben werden. Allerdings sollte man aus Performance-Gesichtspunkten keine DDS beschriebenen logischen Dateien in SQL-Statements verwenden.
Jetzt ans Eingemachte:
Ein SQL-Index wird per definitionem mit einer PageSize von 64K angelegt. Eine DDS-beschriebene logische Datei nur mit 8K. Im Klartext heißt das, über einen SQL-Index können auf einen Schlag mehr Informationen eingelesen werden, als mit einer geschlüsselten logischen Datei.
(Ab Release V5R4 kann überigens die PageSize sowohl bei DDS beschriebenen logischen Dateien als auch bei SQL Indices zwischen 4 und 512 K. Die Default-Werte bleiben für beides unverändert.)
Eine DDS-beschriebene logische Datei kann mit einer anderen DDS-beschriebenen logischen Datei oder einem SQL-Index den Zugriffs-Pfad teilen (shared access path), sofern die gleiche Anzahl oder weniger Schlüssel-Felder in der gleichen Reihenfolge angegeben werden. Wenn eine DDS beschriebene logische Datei mit einem SQL-Index den Zugriffspfad teilt, übernimmt sie auch die größere PageSize.
SQL beschriebene Indices können nur mit anderen SQL Indices den Zugriffspfad teilen, nicht aber mit DDS beschriebenen logischen Dateien (aufgrund der größeren PageSize). Aber SQL Indices können nur den Zugriffspfad teilen, wenn die GLEICHE ANZAHL Schlüssel-Felder (aber nicht weniger!) in der gleichen Reihenfolge angegeben wurde. (Z.T. findet man dies auch in der Literatur falsch erklärt! Wer's nicht glaubt, ausprobieren. Kann über DSPFD geprüft werden.)
Wird ein neuer Index erstellt, mit weniger Schlüssel-Feldern jedoch in der gleichen Reihenfolge wie ein anderer Index, wird ein neuer Zugriff-Pfad erstellt.
Die Anzahl der Zugriffpfade kann sich bei Updates, Inserts oder Deletes negativ auf die Performace auswirken, da alle Zugriffs-Pfade auf die entsprechenden physischen Dateien aktualisiert werden müssen.
Ich denke das war's im groben.
Birgitta
Meine Herren, das ist viel Holz für einen Freitag... aber vielen,vielen Danke für eure Auskünfte :-)
Die Sache mit den Zugriffspfaden ect. muß ich noch mal überdenken. Bisher hab ich auch nur einfache LF gemacht, nix kompliziertes oder so.
Werd das jetz mal testen und schaun,was bei rüberkommt.
Wünsche allen ein schönes Wochenende
Aus RPG-Sicht gibt es noch ein paar wesentliche Unterschiede zwischen DDS-LF und SQL-Index:
Ein SQL-Index ist immer eine Only-Index-LF, während eine DDS-LF sowohl Only-Index als auch Index und zusätzliche Felder enthalten kann (nebst berechneten).
Eine SQL-View ist zwar auch eine LF kann jedoch keinen Index enthalten (order by-Klausel).
Dies entspricht dann einer DDS-LF, wenn diese das Schlüsselwort DYNSLT und keinen Key enthält.
Während eine SQL-Join-View keinen Index enthält, kann eine DDS-Join-LF wiederum einen Index enthalten (mit oder ohne DYNSLT).
Leider gibt es in SQL erst seit kurzem die Select-Option "fetch only x rows", die nun dem typischen SETLL/READE-Paar bzw. verkürztem CHAIN entspricht.
Nun zu meinem Vorschlag:
Arbeitet man mit SQL so gibt es nur PF's (ohne Key), Views und Index (neben Prozeduren, die auch Daten liefern können u.v.m.).
Arbeitet man mit RPG/LE-nativen Zugriffen (also CHAIN/READ usw.) sollte man DDS-LF's verwenden um zusätzliche Zugriffe zu sparen.
Das wirft mir neue Fragen auf:
Was ist eine 'Only-Index-LF'? Heißt das nur 1 Schlüsselfeld oder wie?
Wie gebe ich an ob eine DDS-LF 'Only-Index' oder 'Index + zusätzliche Felder' ist?
Plastisch betrachtet stell ich mir einen Index wie ein Buchindex vor...das ist wahrscheinlich mein Fehler-aber WAS genau ist es denn sonst oder WIE sieht es aus?
Wäre ein View dann vergleichbar mit einem Query? Angucken aber mehr nicht?
Kann ich mit einem Index Sachen berechnen und wieder ausgeben? (also nicht nur stupides angucken wie bei Query)
Eine DDS-LF mit Schlüsselwort DYNSLT und keinen Key hatte ich noch nie-wozu braucht man das?
Meine Kollegen sind leider wenig hilfreich, die sperren sich ziemlich für das Thema.
'Während eine SQL-Join-View' (was ist das?) keinen Index enthält, kann eine DDS-Join-LF(wo brauch man das nun wieder?) wiederum einen Index enthalten (mit oder ohne DYNSLT).
Leider gibt es in SQL erst seit kurzem die Select-Option "fetch only x rows", die nun dem typischen SETLL/READE-Paar bzw. verkürztem CHAIN entspricht.
Leider kann ich deinen Vorschlag nicht wirklich nutzen: ich MUSS SQL nehmen aber sollte mich zuvor erst mal an einer LF probieren (ging ja auch) um dann den Unterschied zu Index rauszufinden.
Gleiches Prinzip wie immer: Keine Ahnung, kaum Hilfe aber "mach mal-probiers halt aus"....super idee,wenn man weder Grundlagen, Aufbau oder Befehle kennt
Wenn du SQL nehmen musst, dann vergiss einfach die DDS !
Per CREATE INDEX beschleunigst du einfach deine Zugriffe, nötig sind sie tatsächlich nicht (beim Update genau eines Satzes aus 1.000.000 kann das dann aber schon mal ein paar Minuten dauern).
Im Index sind Berechnungen nicht möglich.
Per CREATE VIEW kannst du eben "Sichten" incl. Berechnungen über die Daten legen, die die Verarbeitung ggf. vereinfachen.
Ein Select auf einen Index ist nicht möglich, daher kannst du keinen Unterschied zwischen LF und Index per SQL ermitteln.
Ich weiß auch nicht, wozu das nun nötig sein soll.
Wenn du dich mit SQL beschäftigst, dann verwende auch ausschließlich SQL-Methoden (TABLE/INDEX/VIEW). Was die AS/400 dann mit den Objekten treibt ist für die Sache vollkommen unerheblich.
Wichtig sind dann ggf. Joblog-Hinweise (Stichworte STRDBG, QAQQINI) für die Performance.