2

警告: 私はデータベースの照合順序についてほとんど知らないので、明らかな情報があれば事前にお詫びします...

URL を含むデータベース列があります。この列に一意の制約/インデックスを配置したいと思います。

デフォルトの db Latin1_General_CI_AScollat​​ion では、(たとえば) urlhttp://1.2.3.4:5678/someResourceとhttp://1.2.3.4:5678/SomeResourceが等しいと見なされるため、この列に重複が存在することに気付きました。多くの場合、これは当てはまりません...この URL が指すサーバーの種類では、大文字と小文字が区別されます。

そのような列に最も適切な照合は何ですか? 明らかに大文字と小文字の区別は必須ですが、Latin1_General? URL はLatin1_General? 辞書式の順序については気にしませんが、一意のインデックス/グループ化の同等性は重要です。

4

4 に答える 4

1

Latin1_General はコード ページ 1252 ( 1 ) を使用し、URL の使用可能な文字はそのコード ページ ( 2 ) に含まれているため、URL は Latin1_General であると言えます。

大文字と小文字を区別するオプションを選択するだけですLatin1_General_CS_AS

于 2012-08-20T13:19:54.850 に答える
1

rfc3986言います:

ABNF 記法は、US-ASCII コード化文字セット [ASCII] に基づく非負の整数 (コードポイント) になるようにその端末値を定義します。

ウィキペディアによると、許可されている文字は次のとおりです。

Unreserved
May be encoded but it is not necessary
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

Reserved
Have to be encoded sometimes
! * ' ( ) ; : @ & = + $ , / ? % # [ ]

比較操作では、この文字間の競合ではないようです。また、この比較にはHASHBYTES関数を使用できます。

しかし、この種の操作は大きな問題ではありません。大きな問題はそれhttp://domain:80 であり http://domain、同じかもしれません。また、エンコードされた文字を使用すると、URL がエンコードされた文字とは異なるように見える場合があります。

私の意見では、RDBMS はこの種の構造を新しいデータ型として組み込みます: URL、電話番号、電子メール アドレス、MAC アドレス、パスワード、緯度、経度など。照合は役立つと思いますが、この問題は解決しません。

于 2012-08-20T13:46:39.973 に答える