照合の制限と動作 - Amazon Aurora

照合の制限と動作

Babelfish は ICU ライブラリを使用して照合をサポートします。次のセクションでは、Babelfish 照合の既知制限と動作バリエーションをいくつか示しています。

  • Unicode ソートルール

    SQL Server SQL 照合順序は Unicode でエンコードされたデータ (nchar と nvarchar) を一つの方法でソートしますが、Unicode でエンコードされていないデータ (char と varchar) は別の方法でソートします。Babelfish データベースは常に UTF-8 でエンコードされ、データ型に関係なく Unicode ソートルールを常に適用します。したがって、ソート順は nchar と nvarchar の場合と同じく、char と varchar になります。

  • 二次等照合順序

    デフォルトの ICU Unicode 二次等 (CI_AS) 照合では、句読点やその他の英数字以外の文字を数字の前にソートし、英字の前に数字をソートします。ただし、句読点やその他の特殊文字の順序は異なります。

  • 三次照合

    SQL_Latin1_General_Pref_CP1_CI_AS などのSQL 照合順序は TERTIARY_WEIGHTS 関数 をサポートし、CI_AS 照合で等しく比較される文字列が初期に大文字でソートされる機能をサポートします:ABC、ABc、AbC、Abc、aBC、aBc、abC、そして最後にabc。よって、DENSE_RANK OVER (ORDER BY column) 分析関数は、これらの文字列を同じランクとして評価しますが、パーティション内でまず大文字で並べ替えます。

    @colCaseFirst=upper を指定する三次 CS_AS 照合 を明記した ORDER BY 句に COLLATE 句を追加することで、Babelfish でも同様の結果が得られます。ただし、colCaseFirst 修飾子は 3 次と等しい (CI_AS 照合順序のような 2 次ではなく) 文字列にのみ適用されます。したがって、1 つの ICU 照合を使用して 3 次 SQL 照合をエミュレートすることはできません。

    回避策として、BBF_SQL_Latin1_General_CP1_CI_AS 照合順序を使う前に SQL_Latin1_General_Pref_CP1_CI_AS 照合を使用するアプリケーションを変更することをお勧めします。その後、このカラムの ORDER BY 句に COLLATE BBF_SQL_Latin1_General_Pref_CP1_CS_AS を追加します。

  • PostgreSQL は特定のバージョンの ICU で構築されており、照合の 1 つのバージョンにだけ一致させることができます。バージョン間のバリエーションは避けられません。言語は時間と共に進化するため、マイナーなバリエーションも同様です。

  • 文字の拡張

    文字拡張では、1 文字を 1 次レベルの文字シーケンスと等しく扱います。SQL Server のデフォルト CI_AS 照合では文字拡張がサポートされており、ICU 照合ではアクセントが区別されない照合に対してのみ文字拡張がサポートされています。

    文字拡張が必要な場合は、AI 照合を使って比較してください。ただし、このような照合は LIKE 演算子では現在サポートされていません。

  • char および varchar エンコード

    SQL で始まる照合を char または varchar データ型に使用する場合、ASCII 127 より前の文字のソート順は、その SQL 照合の特定のコードページによって決まります。SQL 照合では、char または varchar として宣言された文字列は、nchar または nvarchar として宣言された文字列とは異なるソートされることがあります。

    PostgreSQL はすべての文字列をデータベースエンコーディングでエンコードするため、すべての文字を UTF-8 に変換し、Unicode ルールを使用してソートします。

    SQL 照合では Unicode ルールを使用して nchar データ型と nvarchar データ型がソートされるため、Babelfish はサーバー上のすべての文字列を UTF-8 を使用してエンコードします。Babelfish は、Unicode ルールを使用して char 文字列と varchar 文字列をソートするのと同じ方法で、 nchar 文字列と nvarchar 文字列をソートします。

  • 補足文字

    SQL Server 関数 NCHAR、UNICODE、および LEN は Unicode 基本多言語平面 (BMP) 外のコードポイントの文字をサポートします。対照的に、SC 以外の照合では、サロゲートペア文字を使用して補足文字を処理します。Unicode データ型の場合、SQL Server は UCS-2 を使用して最大 65,535 文字を表すことができます。補足文字を使用する場合は Unicode の全範囲 (1,114,114 文字) を表すことができます。

  • かなを区別する

    日本語の仮名文字 Hiragana と Katakana が異なって扱われた場合、照合はかなを区別する (KS) と呼ばれます。ICU は日本語の照合スタンダードJIS X 4061 をサポートしています。現在非推奨される colhiraganaQ [on | off] ロケール修飾子は KS 照合と同じ機能を提供する場合があります。ただし、SQL Server と同じ名前の KS 照合は現在 Babelfish でサポートされていません。

  • Width-Sensitive

    同じ文字が 半角文字 (半角) と 全角文字 (全角) で別扱いされる場合、照合は 幅を区別する (WS) と呼ばれます。SQL Server と同じ名前の WS 照合は、現在 Babelfish でサポートされていません。

  • バリエーションセレクタ感度

    Variation-Selector Sensitivity (VSS) 照合では、日本語照合における表意文字の変動セレクターを Japanese_Bushu_Kakusu_140 と Japanese_XJIS_140 とで区別します。バリエーションシーケンスは、基本文字と追加のバリエーションセレクターで構成されます。_VSS オプションを選択しない場合、バリエーションセレクターは比較には考慮されません。

    VSS 照合は、現在 Babelfish はサポートされていません。

  • BINとBIN2

    BIN2 照合では、コードポイントの順序に従って文字がソートされます。UTF-8 のバイト単位のバイナリ順序は Unicode コードポイントの順序を保持するため、これが最もパフォーマンスの高い照合になる可能性もあります。Unicode コードポイントの順序がアプリケーションで機能する場合は、BIN2 照合の使用を検討してください。ただし、BIN2 照合を使用すると、文化的に予期しない順序でデータがクライアントに表示されることがあります。小文字への新しいマッピングは時間の経過とともに Unicode に追加されるため、ICU のバージョンによって、LOWER 関数の動作が異なる場合があります。これは BIN2 照合に固有なケースではなく、より一般的な照合バージョニング管理の特殊な不具合ケースです。

    Babelfish は Unicode コードポイント順に照合すため、 Babelfish ディストリビューションで BBF_Latin1_General_BIN2 照合を提供します。BIN 照合では、初期の文字だけが wchar としてソートされます。残りの文字はバイト単位でソートされ、エンコーディングに従ってコードポイント順に効率的にソートされます。このアプローチは Unicode 照合ルールに従わず、Babelfish ではサポートされていません。