View Full Version : SRTSEQ & LANGID Taktik
S.Neinawaie
29-02-16, 14:02
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
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.
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
29-02-16, 15:09
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
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.
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
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.
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
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 (http://www.ibm.com/developerworks/ibmi/library/i-sql-indexs-and-native-io/index.html?ca=drs-)
Birgitta
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 (http://www.ibm.com/developerworks/ibmi/library/i-sql-indexs-and-native-io/index.html?ca=drs-)
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