Einschränkungen und Verhaltensunterschiede von Sortierungen

Babelfish verwendet die ICU-Bibliothek zur Sortierunterstützung. PostgreSQL ist mit einer bestimmten Version der ICU erstellt und kann höchstens mit einer Version einer Sortierung übereinstimmen. Variationen zwischen Versionen sind unvermeidbar, ebenso geringfügige Schwankungen im Laufe der Zeit, während sich die Sprachen entwickeln. Im folgenden Abschnitt werden einige der bekannten Einschränkungen und Verhaltensvarianten von Babelfish-Sortierungen aufgeführt:

• Indizes und Sortierungstypabhängigkeit – Ein Index für einen benutzerdefinierten Typ, der von der International Components for Unicode (ICU)-Sortierungsbibliothek (die von Babelfish verwendete Bibliothek) abhängt, wird nicht ungültig, wenn sich die Version der Bibliothek ändert.

• COLLATIONPROPERTY-Funktion – Sortiereigenschaften werden nur für die unterstützten Babelfish-BBF-Sortierungen implementiert. Weitere Informationen hierzu finden Sie unter Babelfish supported collations table.

• Unterschiede bei Unicode-Sortierregeln – SQL-Sortierungen für SQL Server sortieren mit Unicode codierte Daten (nchar und nvarchar) anders als Daten, die nicht mit Unicode codiert sind (char und varchar). Babelfish-Datenbanken sind immer UTF-8-codiert und wenden Unicode-Sortierregeln unabhängig vom Datentyp immer einheitlich an, sodass die Sortierreihenfolge für char oder varchar die gleiche ist wie für nchar oder nvarchar.

• Sekundär gleiche Sortierungen und Sortierverhalten – Die Standard-ICU-Unicode-Sortierung sekundär gleich (CI_AS) sortiert Satzzeichen und andere nicht alphanumerische Zeichen vor numerischen Zeichen und numerische Zeichen vor alphabetischen Zeichen. Die Reihenfolge der Satzzeichen und anderer Sonderzeichen ist jedoch unterschiedlich.

• Teritiäre Sortierung, Umgehung für ORDER BY – SQL-Sortierungen wie SQL_Latin1_General_Pref_CP1_CI_AS unterstützen die TERTIARY_WEIGHTS-Funktion und die Möglichkeit, Strings zu sortieren, die gleichermaßen in einer CI_AS-Sortierung verglichen werden, die zuerst in Großbuchstaben sortiert werden soll: ABC, ABc, AbC, Abc, aBC, aBc, abC und schließlich abc. Daher bewertet die analytische Funktion DENSE_RANK OVER (ORDER BY column) diese Strings als denselben Rang, ordnet sie jedoch zuerst in einer Partition in Großbuchstaben an.

  Sie können ein ähnliches Ergebnis mit Babelfish erzielen, indem Sie eine COLLATE-Klausel zu einer ORDER BY-Klausel hinzufügen, die eine Tertiäre CS_AS angibt,, welche @colCaseFirst=upper spezifiziert. Der colCaseFirst-Modifizierer gilt jedoch nur für Strings, die tertiär gleich sind (anstatt sekundär gleich wie bei einer CI_AS-Sortierung). Daher können Sie tertiäre SQL-Sollationen nicht mit einer einzigen ICU-Sortierung emulieren.

  Als Problemumgehung empfehlen wir, Anwendungen zu ändern, die eine SQL_Latin1_General_Pref_CP1_CI_AS-Kollation zur Verwendung der BBF_SQL_Latin1_General_CP1_CI_AS-Kollation nutzt. Dann fügen Sie COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS zu einer beliebigen ORDER BY-Klausel für diese Spalte hinzu.

• Zeichenerweiterung – Eine Zeichenerweiterung behandelt ein einzelnes Zeichen als eine Zeichenfolge auf der Primärebene. Die CI_AS-Standardsortierung von SQL Server unterstützt die Zeichenerweiterung. ICU-Sortierungen unterstützen die Zeichenerweiterung nur für akzentunempfindliche Sortierungen.

  Wenn eine Zeichenerweiterung erforderlich ist, verwenden Sie eine AI-Sortierung für Vergleiche. Solche Sortierungen werden derzeit jedoch vom LIKE Operator nicht unterstützt.

• Codierung von char und varchar – Wenn SQL-Sortierungen für char- oder varchar-Datentypen verwendet werden, wird die Sortierreihenfolge für Zeichen vor ASCII 127 durch die spezifische Code Page für diese SQL-Sortierung bestimmt. Bei SQL-Sortierungen können Strings, die als char oder varchar deklariert sind, anders sortiert werden als Strings, die als nchar oder nvarchar deklariert sind.

  PostgreSQL kodiert alle Strings mit der Datenbankkodierung, damit alle Zeichen in UTF-8 konvertiert und nach Unicode-Regeln sortiert werden.

  Da SQL-Sollationen nchar- und nvarchar-Datentypen mithilfe von Unicode-Regeln sortieren, codiert Babelfish alle Strings auf dem Server mit UTF-8. Babelfish sortiert nchar- und nvarchar-Strings genauso wie Char- und Varchar-Strings unter Verwendung von Unicode-Regeln.

• Ergänzende Zeichen – Die SQL-Server-Funktionen NCHAR, UNICODE und LEN unterstützen Zeichen für Codepunkte außerhalb der Unicode Basic Multilingual Plane (BMP). Im Gegensatz dazu verwenden Nicht-SC-Sollationen Ersatzpaarzeichen, um zusätzliche Zeichen zu behandeln. Für Unicode-Datentypen kann SQL Server bis zu 65.535 Zeichen mit UCS-2 oder dem gesamten Unicode-Bereich (1.114.114 Zeichen) darstellen, wenn zusätzliche Zeichen verwendet werden.

• Kana-sensible (KS) Sortierungen – Eine kana-sensible (KS) Sortierung behandelt japanische Hiragana- und Katakana-Kana-Zeichen anders. Die Intensivstation unterstützt den japanischen Sortierstandard JIS X 4061. Der jetzt veraltete colhiraganaQ [on | off] lokale Modifikator bietet möglicherweise die gleiche Funktionalität wie KS-Sortierungen. KS-Sortierungen mit demselben Namen wie SQL Server werden derzeit jedoch nicht von Babelfish unterstützt.

• Breitenempfindliche (WS) Sortierungen – Wenn ein Einzelbyte-Zeichen (halbe Breite) und das gleiche Zeichen, das als Doppelbyte-Zeichen (volle Breite) dargestellt wird, unterschiedlich behandelt werden, wird die Sortierung als breitenempfindlich (width-sensitive, WS) bezeichnet. WS-Sortierungen mit dem gleichen Namen wie SQL Server werden derzeit von Babelfish nicht unterstützt.

• Variationsauswahl-sensible (VSS) Sortierungen – Variationsauswahl-sensible (VSS) Sortierungen unterscheiden zwischen ideographischen Variationsauswahlen in japanischen Sortierungen Japanese_Bushu_Kakusu_140 und Japanese_XJIS_140. Eine Variationssequenz besteht aus einem Basiszeichen plus einem zusätzlichen Variationsselektor. Wenn Sie nicht die _VSS-Option wählen, wird der Variationsselektor im Vergleich nicht berücksichtigt.

  VSS-Sortierungen werden derzeit nicht von Babelfish unterstützt.

• BIN- und BIN2-Sortierungen – Eine BIN2-Sortierung sortiert Zeichen nach Codepunkt-Reihenfolge. Die binäre Byte-für-Byte-Reihenfolge von UTF-8 behält die Reihenfolge der Unicode-Codepunkte bei, daher ist dies wahrscheinlich auch die Sortierung mit der besten Leistung. Wenn die Unicode-Codepunkt-Reihenfolge für eine Anwendung funktioniert, sollten Sie eine BIN2-Sortierung verwenden. Die Verwendung einer BIN2-Sollation kann jedoch dazu führen, dass Daten auf dem Client in einer kulturell unerwarteten Reihenfolge angezeigt werden. Im Laufe der Zeit werden Unicode neue Zuordnungen zu Kleinbuchstaben hinzugefügt, sodass die LOWER-Funktion auf verschiedenen Versionen der Intensivstation unterschiedlich funktionieren kann. Dies ist ein Sonderfall des allgemeineren Sortierungsproblems und nicht als etwas, das für die BIN2-Sollation spezifisch ist.

  Babelfish bietet eine BBF_Latin1_General_BIN2-Kollation mit der Babelfish-Distribution, um in Unicode-Codepunkt-Reihenfolge zusammenzufassen. In einer BIN-Sollation wird nur das erste Zeichen als wchar sortiert. Die verbleibenden Zeichen werden byte für Byte sortiert, effektiv in Codepunkt-Reihenfolge entsprechend ihrer Kodierung. Dieser Ansatz folgt nicht den Unicode-Sollationsregeln und wird von Babelfish nicht unterstützt.

• Nicht deterministische Sortierungen und CHARINDEX-Einschränkung – Für Babelfish-Versionen, die älter als Version 2.1.0 sind, können Sie CHARINDEX nicht mit nicht deterministischen Sortierungen verwenden. Standardmäßig verwendet Babelfish eine Sortierung ohne Berücksichtigung der Groß- und Kleinschreibung (nicht deterministisch). Die Verwendung von CHARINDEX für ältere Versionen von Babelfish löst den folgenden Laufzeitfehler aus:

  nondeterministic collations are not supported for substring searches

  Anmerkung

  Diese Einschränkung und Problemumgehung gelten nur für Babelfish Version 1.x (13.x-Versionen von Aurora PostgreSQL). Babelfish 2.1.0 und höhere Releases haben dieses Problem nicht.

  Dieses Problem können Sie mit einer der folgenden Methoden umgehen:

  • Konvertieren Sie den Ausdruck explizit in eine Kollatierung mit Berücksichtigung der Groß- und Kleinschreibung und wandeln Sie die Groß- oder Kleinschreibung beider Argumente um, indem Sie LOWER oder UPPER anwenden. Der Aufruf SELECT charindex('x', a) FROM t1 führt beispielsweise zu folgender Ausgabe:

    SELECT charindex(LOWER('x'), LOWER(a COLLATE sql_latin1_general_cp1_cs_as)) FROM t1

  • Erstellen Sie eine SQL-Funktion f_charindex und ersetzen Sie CHARINDEX-Aufrufe durch Aufrufe der folgenden Funktion:

    CREATE function f_charindex(@s1 varchar(max), @s2 varchar(max)) RETURNS int
    AS
    BEGIN
    declare @i int = 1
    WHILE len(@s2) >= len(@s1)
    BEGIN
      if LOWER(@s1) = LOWER(substring(@s2,1,len(@s1))) return @i
      set @i += 1
      set @s2 = substring(@s2,2,999999999)
    END
    return 0
    END
    go