SRTSEQ & LANGID Taktik

[BenderD]

Hallo

Derzeit erstellen wir alle PF/LF mit SRTSEQ *LANGIDSHR & LANGID DEU.
Interaktive Jobs laufen mit LANGIDSHR/DEU.

Nun möchten wir sukzessive unsere PF/LF auf SQL Tables/Indizes/Views umstellen.
Allerdings bin ich mir nicht sicher welche SRTSEQ "Einstellung" am besten geeignet ist.

Create Table mit *HEX
Create Index mit *LANGIDSHR/DEU
In (SQL)RPGLE die SRTSEQ *JOB setzen

Oder überhaupt eine komplett andere Vorgehensweise?

Danke,
Sam

... ich plädiere für oder überhaupt!!!

Sinn und Zweck der Umstellung von DDS auf DDL ist in erster Linie die Entkoppelung von Datenbank und Anwendung und diesen Effekt erreichst Du nur, wenn Du den RLA komplett loswirst und aus SQL ausschließlich auf Views zugreifst und im Order By kannst Du sortieren, wie Du willst, nach was immer Du willst. Den RLA ersetzt man dann durch Aufrufe von Datenbank Modulen, die einem die entsprechenden Konstrukte bereitstellt, die vorher im RLA da waren.
Was man dann für Indexe braucht, sagt einem die Datenbank schon (STRDBMON ist Dein Freund). BTW: fehlende Indexe führen nicht immer zum Table Scan und die Verwendung eines Index muss nicht immer die Beste Zugriffsmethode sein.
Bei dieser Vorgehensweise kann man auch mit geringem Aufwand Sortierung und Auswahl in vorhandenen Programmen völlig flexibel machen, mit wesentlich verbesserter Software Ergonomie.

D*B

[Fuerchau]

Das Stichwort heißt "Collating Sequence" und ist bei längerem nachlesen wohl doch eher rudimentär gelöst.
Die Sortierung nach Wertigkeit, also "EeÉé" gleichwertig zu betrachten ist nicht mit der Upper/Lower-Funktion zu erreichen.
Hierfür benötigt es tatsächlich einer SRTSEQ.
Diese kann aber nicht auf Feldebene o.ä. angegeben werden sondern nur in der Verbindung.
D.h., bei embedded SQL per "set option ..." bzw. bei ODBC/JDBC im Connectionstring.
Der Nachteil ist aber, dass dies dann für die gesamte Laufzeit gilt!
Mache ich den SRTSEQ <> *HEX wird jeder Vergleich (Where, Order, case ...) nach dieser Sequenz durchgeführt was durchaus nachteilig auf die Anwendung wirken kann.

Einen Translate mit Angabe einer Collation oder eines TBL-Objektes kann ich in der Doku nicht finden um die Sortierung auf eine einzelne Abfrage, z.B. Matchcodesuche, Anordnung nach Namen zu beschränken.

[BenderD]

Das Stichwort heißt "Collating Sequence" und ist bei längerem nachlesen wohl doch eher rudimentär gelöst.
Die Sortierung nach Wertigkeit, also "EeÉé" gleichwertig zu betrachten ist nicht mit der Upper/Lower-Funktion zu erreichen.
Hierfür benötigt es tatsächlich einer SRTSEQ.
Diese kann aber nicht auf Feldebene o.ä. angegeben werden sondern nur in der Verbindung.
D.h., bei embedded SQL per "set option ..." bzw. bei ODBC/JDBC im Connectionstring.
Der Nachteil ist aber, dass dies dann für die gesamte Laufzeit gilt!
Mache ich den SRTSEQ <> *HEX wird jeder Vergleich (Where, Order, case ...) nach dieser Sequenz durchgeführt was durchaus nachteilig auf die Anwendung wirken kann.

Einen Translate mit Angabe einer Collation oder eines TBL-Objektes kann ich in der Doku nicht finden um die Sortierung auf eine einzelne Abfrage, z.B. Matchcodesuche, Anordnung nach Namen zu beschränken.

... set option im SQL wirkt auf Module Ebene und Job Ebene gibt es bei SQL eh' nicht, das geht bis zur Connection Ebene maximal und das ist bei korrekter Vorgehensweise ACTGRP. Performance kann bei exotischen Sortierungen Redundanz (:= extra Sortierfeld) erfordern, damit geht dann alles. Das Feld kann bei SQL hidden sein und per Trigger gefüllt werden - damit geht selbst abstruses flott wie Harry.

D*B

[B.Hauser]

Nur so als Anmerkung:
Man kann auch SQL Indices mit Sortier-Reihenfolge erstellen.
Ebenso kann man in SQL Indices zusätzliche Schlüssel-Felder in Verbindung mit SQL skalaren Funkionen, Case-Anweisungen etc. generieren (ohne dass man dafür die Datei/Tabelle erweitern muss).
... und SQL Indices können mit native I/O wie ganz normale DDS beschriebene logische Dateien verarbeitet werden.

Weitere Informationen gibt es hier:
SQL indexes and native I/O – no contradiction

Birgitta

[BenderD]

Nur so als Anmerkung:
Man kann auch SQL Indices mit Sortier-Reihenfolge erstellen.
Ebenso kann man in SQL Indices zusätzliche Schlüssel-Felder in Verbindung mit SQL skalaren Funkionen, Case-Anweisungen etc. generieren (ohne dass man dafür die Datei/Tabelle erweitern muss).
... und SQL Indices können mit native I/O wie ganz normale DDS beschriebene logische Dateien verarbeitet werden.

Weitere Informationen gibt es hier:
SQL indexes and native I/O – no contradiction

Birgitta

... nur so als Anmerkung zur Anmerkung: Indexe werden auf Tabellen erstellt. RLA bleibt die Mächtigkeit der SQL Views unzugänglich. Instead Trigger können nicht eingesetzt werden, flexible Sortierung erfordert umfangreiche Änderungen und unterbleibt. Die Folge davon: die RLA Schinken behindern unbedingt erforderliche Normalisierung vrohandener Datenbanken.

D*B

[Fuerchau]

Man kann zwar jede Menge Indizes, auch berechnete, erstellen. Einzig dem Optimizer bleibt es dann überlassen ob er diese auch verwendet. Nur weil ich dann per RLA auf diese Indizes zugreifen kann ist das keine reelle Option für SQL-Anwendungen insbesonders wenn diese auch noch per ODBC/JDBC auf die DB zugreifen.
SQL-mäßig, wie oben beschrieben, habe ich nur bei der Verbindung Einfluss auf Sortierungen anders als *HEX. Ich habe keine SQL-Funktion gefunden mit der ich eine wertige Sortierung wie LANGIDSHR zu erstellen. Andere DB's kennen sowas wie "Collating Sequence" auf Feldebene um genau das dann zu erreichen.
Ich scheitere ja schon bei der Where-Klausel zu bestimmen, wie denn die Suche "Name between 'Ae' and 'Af'" zu interpretieren ist. Bei *HEX fallen ja "é" usw. raus, bei LANGIDSHR sind sie drin.

Wie bestimme ich das dann ohne "Set option srtseq=*langidshr" ?
Denn spätestens eine Where-Klausel auf z.B. "Teilenummer = 'ABC'" führt zu einem Tablescan da es keinen LANGID-Index auf das Feld gibt.

[BenderD]

... sicherlich muss ich eine collating sequence angeben, wenn ich die Funktionalität haben will, aber wer sagt Dir denn, dass die Angabe einer Collating sequence zum full table scan führt? Und eingrenzen kann ich die Wirksamkeit der collating sequence bei embedded SQL, indem ich mehr als ein Modul benutze. Es empfiehlt sich ohnehin die Zugriffe in ein Data access layer zu verlagern und dort die dirty reads von den Transaktions sicheren zu trennen, erstere arbeiten mit coll. s., letztere ohne. Bei ODBC, JDBC, brauche ich dann gegebenen Falls mehr als eine Connection, aber wo ist da das Problem?
Sicherlich hängt da einiges auch vom Datenbank Designn ab, eine Teilenummer mit seltsamen Zeichen ist sicherlich nur die zweitbeste Idee, aber selbst das ist heilbar mit einem zusätzlichen Sortierfeld, das man durchaus verdeckt füllen kann.
Für SQL sehe ich da nur lösbare Herausforderungen, Rekord Löffel würde ich ohnehin grundsätzlich von abraten.

D*B

[S.Neinawaie]

Hallo

Herzlichen Dank für die Antworten - ihr habt mir weitergeholfen

LG,
Sam