[NEWSboard IBMi Forum]
Seite 1 von 3 1 2 ... Letzte
  1. #1
    Registriert seit
    Nov 2009
    Beiträge
    208

    LF, View, Index

    Guten Tag

    Wir haben im Rahmen der DSGVO eine 'Universal Datei' erstellt.

    Dateiname
    Key
    Feld
    Wert
    herkunft
    Grund
    Datum
    ....

    In der Datei steht im Dateiname z.b.
    Mandant
    Kunde
    Ansprechpartner
    ...

    das Feld Key beinhaltet den Key des Datensatzes in der Datei also z.B.
    DEB1234567
    DIV3317877
    CRD1144788

    im Mandantenstamm ist der key in 2 Feldern
    Art = DEB und
    Nr. = 1234567

    Viele Pgmme arbeiten mit dieser einen Datei.

    Nun habe ich View's erstetellt, JE Dateinamen, die den Key Typgerecht wieder in Einzelfelder zerlegt.

    Aber ich kann keinen Index auf die View legen!
    und ein

    create index Lib/indexname on Datei
    dec(substr(key, 1, 7), 7, 0) as NR,
    dec(substr(Keyxx, 8, 1), 1, 0) as N2

    geht auch nicht.

    Wie bekomme ich die 'schnelle' Zugriffe.

    Vielen Dank
    Dietlinde Beck

  2. #2
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... works as designed.

    D*B ,erschüttert, wie man auf solche Ideen kommen kann!
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  3. #3
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Ein Index kann immer nur auf eine einzige Physische Datei oder Tabelle gelegt werden!

    Wie sieht denn Deine View aus?
    Wie werden die Tabellen verknüpft?

    Abh. von dieser JOIN-Anweisung kannst Du überlegen, wie die Indices auf den einzelnen Tabellen/physischen Dateien aussehen müssen.
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  4. #4
    Registriert seit
    Nov 2009
    Beiträge
    208
    @Herr Bender
    diese Form hat sich seid mehreren Jahren in mehreren Anwendungen für dynamische Sammelbecken bewährt. Nicht erst seid der DSGVO. Aber leider müssen wir nun gezielt, d.h. über eine Verknüpfung zur orginal Datei auf die Daten zugreifen.

    @Frau Hauser
    Die view's haben keine join.

    Die View's:
    select f1, f2, dec(substr(key, 1, 7), 7, 0) as NR,
    dec(substr(Keyxx, 8, 1), 1, 0) as N2, f5, f6, f7 from datei where f1 = 'DATEINAME'

    oder

    select f1, f2, substr(key, 1, 3) as Art,
    dec(substr(Keyxx, 4, 7), 7, 0) as Nr, f5, f6, f7 from datei where f1 = 'DATEINAME'

    Jetz überlege ich, ob ich zusätzlich VIEW's auf die Basidateien lege, und dort ein Feld generiere, das den Key in meiner Sammeldatei darstellt.

    Aber eigendlich ist das falsch herum

    Schade das SQL das nicht kann

    DiBe

  5. #5
    Registriert seit
    Nov 2020
    Beiträge
    315
    Hallo Dietlinde,

    Was für eine Fehlermeldung liefert er dir beim erstellen des Index:
    create index Lib/indexname on Datei
    dec(substr(key, 1, 7), 7, 0) as NR,
    dec(substr(Keyxx, 8, 1), 1, 0) as N2

    Normal kann man schon beim Index die Spalten manipulieren.
    Ich kann mir vorstellen, dass du hier beim Substring einen Konvertierungsfehler haben kannst, wenn der Wert NICHT Nummerisch ist.

    lg Andreas

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Blödes Konzept aber:

    Auf Views kannman keinen Index erstellen, aber man kann einen berechneten Index incl. Where auf die PF erstellen.

    Dies nützt aber nur etwas, wenn die Whereklausel genaue diese Bedingung des Index auch verwendet.
    Also der Index wird mit "...dec(...) " erstellt, dann muss die Whereklausel auch "... where dec(...) .." enthalten.

    Dein Hauptproblem ist allerdings die Konvertierung des Keys, wenn die Struktur für alle Konvertierungen nicht identisch ist.
    Seit V6R1 hat sich die SQL-Logik leider etwas geändert:

    select dec(f1, 5, 0) from myfile where key = 'D1';

    Die Umwandlung in dec() wird vor der Prüfung der Whereklausel durchgeführt!
    K.a. warum das so ist. D.h., wenn die Konvertierung fehlschlägt wird die Whereklausel nicht mehr ausgeführt. Du musst also in deine Umwandlung eine zusätzliche Prüfung auf den Inhalt einbauen.
    Performant wird das dann nicht mehr.

    M.a.W.: Dein Konzept funktioniert nur dann, wenn die Struktur der variablen Schlüssel identisch ist.
    Da das wohl nicht gewährleistet ist, hast du da schlechte Karten.

    Alternativ kannst du Service-Programme bauen, die die Zugriffe entsprechend gestalten. Die Programme dürfen dann nur über die Services zugreifen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Nov 2009
    Beiträge
    208
    @Andreas

    create index Lib/indexname on Datei
    dec(substr(key, 1, 7), 7, 0) as NR,
    dec(substr(Key, 8, 1), 1, 0) as N2

    SQL0104
    Nachricht . . . : Token DEC ungültig. Gültige Token: IN NOT KEEP NONE PAGE
    UNIT WITH ALLOW DEFER USING DEFINE EXTEND.


    @Herr Fuerchau

    um z.b. 100erte von Maschinen Daten zu historisieren von dehnen sich 1/2 sekündlich 0-3 ändern, wäre es Wahnsinn
    a) je Zeittakt den gesammten Satz mit > 1000 Byte zu speichern
    b) Je Feld eine eigene Historie zu führen
    c) je Produktlinie (die bestimmt den key) eine Historie zu führen
    d) die Kombination aus b und c

    Da hat sich dieses Konzep sehr gut bewährt.
    Und solange wir mit RPG arbeiten, sind die genauen zeilichen Abläufe sehr einfach und schnell dar zu stellen.

    Auch in unsere DSGVO Verarbeitung ist dies bisher ohne Probleme, schnell und performant, mit RPGLE.

    Leider zieht bei uns die Form der Modernisierung ein, die alles alte schlecht findet. Es soll nur noch mit SQL gearbeitet werden und die Schwächen vom SQL aber auch Java + (teilweise) Php werden als Designfehler der > 40 Jahre alten Anwendung verkauft.
    Diese gibt es sicherlich. Aber an ganz anderen Stellen in der Verarbeitung.

    Ich werde mich dann also dafür einsetzen, das wir weiter "ALT" und funktionierend mit RPG arbeiten anstatt 'Modern' und dafür alles umstellen.

    Vllt hat ja Andreas noch einen Tipp

    Vielen Dank an Euch
    Dietlinde Beck







  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.206
    Wie wäre es, SQL mit einer Table-Function und Proceduren zu erweitern?
    Dies sollte doch konzeptionell ebenso umsetzbar sein.

    In der Microsoft-Fraktion wird auch gerne empfohlen, für alles und jedes eine SP (Strored procedure) zu verwenden, da dies ja native in der DB läuft und somit von Wartezeiten im (entfernten) Client unabhängig zu sein.

    https://www.ibm.com/docs/en/i/7.1?to...considerations

    Auch für Insert/Updates/Deletes kann man genauso ein SQL-Call o.ä. durchführen.
    Konzeptionell handelt es sich daher um SQL-Erweiterungen, die doch ebenso zulässig sein sollten.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Leider zieht bei uns die Form der Modernisierung ein, die alles alte schlecht findet. Es soll nur noch mit SQL gearbeitet werden und die Schwächen vom SQL aber auch Java + (teilweise) Php werden als Designfehler der > 40 Jahre alten Anwendung verkauft.
    Nicht alles was früher geklappt hat war auch gut! Da könnte man tausende von Beispielen nennen.
    ... allerdings habt Ihr m.E. mit der Modernisierung an der falschen Stelle angefangen.
    Ihr hättet zuerst die Dateien/Tabellen bereinigen sollen.
    So etwas geht und wenn gewährleistet werden soll, dass auch die alten Schinken noch weiterhin laufen, kann man in 2 Schritten vorgehen:
    1. Zusätzliche Spalten in denen die aufgedrößelten Werte stehen
    2. ein zusätzlicher Trigger, der die alten und neuen Spalten beim Ändern der Schlüssel-Werte oder beim Einfügen der Schlüssel-Wert beim Insert automatisch gerade zieht.

    Dann könnt Ihr Zugriffswege über die neuen Spalten legen. Die alten Programme funktionieren wie bisher und in den neuen Programmen wird nur noch auf die neuen Spalten zugegriffen.
    ... dann könnt Ihr gemütlich alles umstellen und zum Zeitpunkt x, wenn kein Zugriff mehr auf die alten Spalten erfolgt können die alten Spalten, sowie die Trigger entfernt werden.

    Für die JOINs wäre es allerdings besser wenn in den Tabellen mit künstlichen Schlüssel (z.B. Identity Columns) gearbeitet wird, die auch in den abh. Dateien integriert werden.
    Auch hier muss man natürlich Zwischenschritte machen um sicherzustellen, dass die Anwendung weiterläuft. Wenn die Joins jedoch in entsprechenden Views hinterlegt werden und die Zugriffe nur noch über diese Views erfolgen, kann man auch hier nach und nach (richtig) umstellen. Es muss lediglich die Verknüpfung in der View angepasst werden. Eine Kompilierung ist nicht erforderlich, so lange die Spalten gezielt ausgewählt wurden.
    Dem Benutzer/Programmierer, der die View verwendet ist es egal ob und wie die Verknüpfung erfolgt, Hauptsache er bekommt die richtigen Daten.
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  10. #10
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von dibe Beitrag anzeigen
    Die View's:
    select f1, f2, dec(substr(key, 1, 7), 7, 0) as NR,
    dec(substr(Keyxx, 8, 1), 1, 0) as N2, f5, f6, f7 from datei where f1 = 'DATEINAME'

    oder

    select f1, f2, substr(key, 1, 3) as Art,
    dec(substr(Keyxx, 4, 7), 7, 0) as Nr, f5, f6, f7 from datei where f1 = 'DATEINAME'

    Jetz überlege ich, ob ich zusätzlich VIEW's auf die Basidateien lege, und dort ein Feld generiere, das den Key in meiner Sammeldatei darstellt.
    ... die verhuddelten Keyfeder für die Basisdatei in eine view zu packen, wird wohl wenig helfen, Nachhaltiger wäre es, der Basisdatei einen key zu verpassen (könnte ein generierter sein) und eine view draufzustellen, die diesen weglässt (kann auch eine DDS erstellte sein, dann merken vorhandene Altanwendungen nix davon.
    Die Historiendatei hätte dann einen compound key aus Dateiname und dem neuen Kunstkey.

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  11. #11
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Wie wäre es, SQL mit einer Table-Function und Proceduren zu erweitern?
    Um eine Tabellen-Funktion oder eine Stored Procedure, die Result-Sets ausgibt, performant ausführen zu können sind ebenfalls die richtigen Zugriffswege erforderlich.
    Stored Procedures können nicht in SELECT-Statements angegeben werden.
    UDTFs mit mehr als einem Statement sind für den Query-Optimizer BLACK-Boxes, werden unahb. vom endgültigen SELECT-Statement optimiert (was manchmal dann eben nicht so optimal ist!)

    ... und solange man alles mit einem SQL-Statement erschlagen kann, warum überhaupt eine UDTF erstellen, wenn man stattdessen eine View verwenden kann?
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  12. #12
    Registriert seit
    Nov 2009
    Beiträge
    208
    Zitat Zitat von BenderD Beitrag anzeigen
    ...
    Die Historiendatei hätte dann einen compound key aus Dateiname und dem neuen Kunstkey.

    D*B
    Ja, so einen automatisch generierten 'Kunstkey' haben wir damals überlegt.
    Da wir aber noch mit DDS Dateien und RPG Write arbeiten hätte ein Trigger diese Nr vergeben müssen.
    Das wiederum hätte die Anwendung verlangsamt (Lfnr lesen, erhöhen, speichern) bei mehreren 100 Anwendern

    Ich geben gerne zu, zu diesem Thema (automatisch vergebener Key in einer PF) nicht viel zu wissen.
    Literatur / Infos nehme ich gerne!
    Was ich aber weis ist, das das nicht nebenbei mal eben ein zu führen ist.

    RPG kann es. Der Aufwand ist überschaubar, lesbar ist es allemal.

    Vielen Dank
    Dibe

Similar Threads

  1. SQL index auf view
    By dibe in forum IBM i Hauptforum
    Antworten: 14
    Letzter Beitrag: 01-07-18, 17:27
  2. SQL View mit Index/Key
    By malzusrex in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 19-10-16, 19:53
  3. Antworten: 4
    Letzter Beitrag: 19-07-16, 12:44
  4. LF / SQL index
    By woodstock99 in forum NEWSboard Programmierung
    Antworten: 31
    Letzter Beitrag: 18-03-15, 14:29
  5. Cobol View und Index (V5R4)
    By KingofKning in forum NEWSboard Programmierung
    Antworten: 6
    Letzter Beitrag: 29-12-14, 13:01

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •