SQL Index DBCS-fähig

[Anton Gombkötö]

das mit dem "G" in der DDS hatte ich komplett verdrängt. :-)

Ich wollte eigentlich nur ausdrücken, dass, wenn man heute eine internationale Anwendung erstellt, alles, wo "DBCS" oder "Graphic" draufsteht, getrost ignorieren kann, das bringt einen nicht weiter.
Zumindest nach meiner Erfahrung.

(Wenn wir schon bei i-Pünktchen sind: "Unicode" ist der eine, ganz große Zeichensatz. UTF ist eine mögliche Kodierung.)

Habe gerade eine kleine Test-Datei erstellt, ein DSPFD des Index sagt "DBCS-fähig: Ja". (V7R1)

CREATE TABLE TESTU (FELD1 VARgraphic (10 ) CCSID 13488 NOT
NULL WITH DEFAULT)                                                 
CREATE INDEX testu1 ON TESTu (FELD1) 

[BenderD]

das mit dem "G" in der DDS hatte ich komplett verdrängt. :-)

Ich wollte eigentlich nur ausdrücken, dass, wenn man heute eine internationale Anwendung erstellt, alles, wo "DBCS" oder "Graphic" draufsteht, getrost ignorieren kann, das bringt einen nicht weiter.
Zumindest nach meiner Erfahrung.

(Wenn wir schon bei i-Pünktchen sind: "Unicode" ist der eine, ganz große Zeichensatz. UTF ist eine mögliche Kodierung.)

Habe gerade eine kleine Test-Datei erstellt, ein DSPFD des Index sagt "DBCS-fähig: Ja". (V7R1)

CREATE TABLE TESTU (FELD1 VARgraphic (10 ) CCSID 13488 NOT
NULL WITH DEFAULT)                                                 
CREATE INDEX testu1 ON TESTu (FELD1) 

... meine Rede: Bug => Fehlermeldung an IBM.

Ich denke, ihr machts euch ein bisschen einfach:

UCS2 und UCS4:= Unicode für Arme und Kranke
- Subset von Unicode mit feste Länge von jedem Zeichen
- für Indexbäume relativ ein´fach handhabbar

UTF8 und UTF16:= the real stuff
- kann heute (und in absehbarer Zukunft) alle Zeichen
- arbeitet mit variabel langer Codierung
- "häufige" (bei UTF8 wenige, bei UTF16 ala UCS2) Zeichen fix codiert
- "seltene" Zeichen mit einer Art escaped Entity Darstellung
- gleich aussehende Zeichen können unterschiedlche Codierungen haben
- für Indexbäume problematischer

D*B

[Fuerchau]

Die Speicherung in UTF-8 ist ja ganz nett, aber je nach Implementation scheitert man dann spätestens beim Vergleich, wenn die zu vergleichende Zeichenfolge nicht auch UTF-8 ist.
In diesem Fall wird ggf. unter Verlusten in UCS2 konvertiert.

Auch der SUBSTR von UTF8 ist von der Implementierung abhängig.
Ggf. wird in UCS2 umgewandelt, der SUBSTR durchgeführt und in UTF8 zurückgewandelt.
Es kann aber auch schiefgehen.

Native UTF8/16-Zeichenfolgen werden eher im Programm in Strings (UCS2) vor der weiterverarbeitung konvertiert.

Ich habe da noch keine UCS4-Implemtierung gesehen, die dies alles korrekt behandeln würde.

Zumindest für die reine DB-Speicherung würde ich von UTF8 abraten.

Wobei Oracle generell NCHAR's als UTF-8 speichert und die Länge dabei in "Bytes" und nicht in "Zeichen" angegeben wird.
Also NCHAR(1) geht zwar, aber kann halt keine Sonderzeichen wie Umlaute aufnehmen.

[andreaspr@aon.at]

Wobei Oracle generell NCHAR's als UTF-8 speichert und die Länge dabei in "Bytes" und nicht in "Zeichen" angegeben wird.

Wie das Oracle Speichert UTF-8, UTF-16 (und ich glaube auch UCS2) wird bei der Installation der Datenbank festgelegt und kann im nachhinein auch nicht mehr einfach geändert werden.

[Anton Gombkötö]

Da die Leute, deren Namen und Adressen, die ein system i in ihren Datenbanken stehen hat, lauter arme und kranke Namen haben, sollte man mit UCS-2 noch eine Weile ganz gut durchkommen.
Aber stimmt schon, wenn wir mehr Geschäfte mit Klingonen machen werden, müssen wir uns was für die effiziente Suche nach deren Namen überlegen. ;-)
Im IFS schaut die Sache anders aus; da ist UTF-8 wohl fast immer die beste Wahl. (XML, HTML, Mails, etc.)

[BenderD]

Da die Leute, deren Namen und Adressen, die ein system i in ihren Datenbanken stehen hat, lauter arme und kranke Namen haben, sollte man mit UCS-2 noch eine Weile ganz gut durchkommen.

... den Einwänd hatte ich vön Dir äm wenigsten erwärtet.
Wo hättest Du Dich denn am liebsten hinsortiert? Hinter oder vor die Gombko... oder passte es auch vor die Gombka... oder hinter die Gombku...

Und was machen wir denn mit dem Florian Übelacker, wenn der nicht bei U einsortiert ist, findet den doch keiner...

D*B

[Anton Gombkötö]

Sortierung in Unicode. Oder mögliche Kodierungen für ein "ö".
Ich halte es für unnötigen Aufwand und Performancevergeudung, nun alle "internationalen" Felder auf UTF-8 umzustellen. UCS-2 reicht auch und ist in RPG gut unterstützt. Im Gegensatz zu UTF-8.
Ich bin schon froh, wenn ich auf meinen Kontoauszügen zwei "ö"s habe. Das hat schon Jahrzehnte gedauert.