View Full Version : 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
... works as designed.
D*B ,erschüttert, wie man auf solche Ideen kommen kann!
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.
@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
Andreas_Prouza
03-02-22, 16:54
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
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.
@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
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?topic=functions-table-function-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.
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.
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