View a markdown version of this page

Einschränkungen und Verhaltensunterschiede von Sortierungen - Amazon Aurora

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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 Unicode-encoded Daten (ncharundnvarchar) anders als Daten, die nicht Unicode-encoded (charundvarchar) sind. Babelfish-Datenbanken sind immer UTF-8 codiert und wenden unabhängig vom Datentyp immer einheitlich Unicode-Sortierregeln an, sodass die Sortierreihenfolge für char oder dieselbe varchar ist wie für oder. nchar nvarchar

  • Secondary-equal Kollationen und Sortierverhalten — Die standardmäßige ICU Unicode-Kollation secondary-equal (CI_AS) sortiert Satzzeichen und andere nichtalphanumerische 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 Zeichenketten mit der Datenbankkodierung, sodass alle Zeichen nach Unicode-Regeln konvertiert UTF-8 und sortiert werden.

    Da SQL-Kollationen die Datentypen nchar und nvarchar nach Unicode-Regeln sortieren, codiert Babelfish alle Zeichenketten 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. Bei Unicode-Datentypen kann SQL Server bis zu 65.535 Zeichen oder den gesamten Unicode-Bereich (1.114.114 Zeichen) darstellen UCS-2, wenn zusätzliche Zeichen verwendet werden.

  • Kana-sensitive (KS) -Sortierungen — Eine Kana-sensitive (KS) -Sortierung ist eine Sortierung, bei der japanische Kana-Zeichen unterschiedlich behandelt werden. Hiragana Katakana 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.

  • Width-sensitive (WS) -Sortierungen — Wenn ein Einzelbyte-Zeichen (halbe Breite) und dasselbe Zeichen, das als Doppelbyte-Zeichen (volle Breite) dargestellt wird, unterschiedlich behandelt werden, wird die Sortierung als breitenabhängig (WS) bezeichnet. WS-Sortierungen mit dem gleichen Namen wie SQL Server werden derzeit von Babelfish nicht unterstützt.

  • Variation-selector sensible (VSS) Kollationen — Bei sensitiven Kollationen (VSS) wird zwischen ideografischen Variation-selector Variationsselektoren in japanischen Kollationen und unterschieden. Japanese_Bushu_Kakusu_140 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 Byte-für-Byte-Binärreihenfolge von UTF-8 behält die Reihenfolge der Unicode-Codepunkte bei, sodass diese Sortierung wahrscheinlich auch die leistungsstärkste ist. 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.

  • Non-deterministic Kollationen und CHARINDEX-Beschränkung — Für Babelfish-Versionen, die älter als Version 2.1.0 sind, können Sie CHARINDEX nicht mit nicht deterministischen Kollationen 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