SRTSEQ & LANGID Taktik

[S.Neinawaie]

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

[Fuerchau]

Create Table mit *HEX geht gar nicht...
Solange du Felder als [VAR]CHAR und nicht [VAR]BINARY anlegst, bekommen die Felder grundsätzlich deine JobCCSID als CCSID eingestellt, wenn diese *HEX ist dann ist es die DefaultCCSID.
Eine SRTSEQ LANGIDSHR bedeutet "nicht casesensitive", also Groß/Klein nicht relevant und eéè... werden eingereiht.
Die SRTSEQ in RPG hat nur auf die internen Sort/Lookup-Funktionen Auswirkungen und nicht mehr auf den bereits erstellten Index.
Eine SRTSEQ kann ich bei Create Index nicht mehr entdecken, was sich ja dadurch erklärt, dass die CCSID auf Feldebene festgelegt wird.
Hier ist eine caseinsensitive CCSID anzuwenden.
Andererseits arbeitet SQL ja nun anders. Man kann also einen Index mit "upper(Name)" erstellen, der beim Where/Order usw. verwendet wird wenn man z.B. "where upper(Name) = ..." oder "order by upper(Name)" verwendet.

[Fuerchau]

Nachtrag:
Collating sequence: Any index created over columns containing SBCS or mixed
data is created with the collating sequence in effect at the time the statement is
executed. For collating sequences other than *HEX, the key for SBCS data or mixed
data is the weighted value of the key based on the collating sequence.

M.a.W., abhängig von der Jobumgebung wird der Index erstellt und daskann nicht mehr explizt angegeben werden.

Per SQL "SET OPTION SRTSEQ=..." werden die Vergleichsbedingungen für jeden SQL definiert. Ich kann da also nicht mehr tabellenspezifisch unterscheiden.

[andreaspr@aon.at]

Du musst auch auf die Performance aufpassen.
Wenn der ausführende Job oder das Programm eine andere Einstellungen hat als die DB dann kann es passieren dass diverse Indice aus Konvertierungsgründen nicht mehr genommen werden können.
Ein Table Scan ist dann die Folge.

lg Andreas

[Fuerchau]

Das ist auch wieder korrekt. Mit SQL steht man da etwas auf dem Schlauch, wenn man versucht alte Methoden auf SQL anzuwenden.
Sprachneutral ist auf jeden Fall die Verwendung von UCS2 (NCHAR, NVARCHAR) was ja auch bei RPG durch den Feldtyp "C" unterstützt wird.
Wenn dann also ein Index per Job LANGIDSHR erstellt wird, dann sollte das mit UCS2 sprachneutral funktionieren. Ansonsten hat man da tatsächlich schlechte Karten.

Aber ggf. weiß Birgitta da ja was genaueres.

[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