1

ADSに大文字と小文字を区別しないUnicode文字フィールドタイプがないのはなぜだろうと思っていました。

NVarCharフィールドへのインデックスの照合で大文字と小文字を区別しないように設定できますが、を使用した単純なクエリでWHERE field = 'HeLlO WoRlD'は値が見つかりません'Hello World'か?

私はそれWHERE field = 'HeLlO WoRlD' COLLATE ads_default_ciがうまくいくことを知っていますが、すべての比較に対してそれを行うことはオプションではありません。

CiCharフィールドタイプはUnicodeに対応していません(他の問題を引き起こすUTF-8文字列をそこに格納しない限り)。

4

1 に答える 1

2

基本的に、通常の文字フィールドとは異なり、Unicode はすべての言語の文字を格納できるため、特定の照合/言語が関連付けられていません。照合順序は、それがどのように使用され、索引付けされ、またはソートされたかによって決まります。NVarCiChar フィールドを定義する場合、言語/ロケール (英語はフランス語やドイツ語とは大文字と小文字の区別が異なります) をそのようなフィールド タイプに関連付ける必要があり、システムが不必要に複雑になります (英語の ci がフィールドは、ドイツの ci フィールドと比較する必要があります)。

ciChar 型はいくつかの点で使いやすいですが、欠点もあります。主な理由は、標準ではないため、他の DB に移植できず、コードで特別な処理が必要になることです。柔軟性が低いです。ciChar フィールドを通常の char フィールドと比較しようとすると問題が発生します。このような比較には COLLATE 句が必要です。COLLATE 句を使用する比較的標準的な方法は、大文字と小文字を区別しない比較をより明確な方法で柔軟にサポートするため、大文字と小文字を区別しない Unicode フィールドは必要ないと判断しました。複数の COLLATE 句の使用を避けるために、SQL ステートメント ハンドルに大文字と小文字を区別しない Unicode 照合順序を指定することにより、大文字と小文字を区別しない Unicode 文字列の比較も簡単に実行できます。

于 2012-09-28T16:02:13.133 に答える