SQL ServerでVARCHAR / CHARの代わりにNVARCHAR / NCHARを使用する必要があるのはいつですか？

https://stackoverflow.com/questions/612430

03-07-2019
|

質問

Unicode型を使用する必要がある場合、ルールはありますか？

ほとんどのヨーロッパ言語（ドイツ語、イタリア語、英語、...）が同じデータベースのVARCHAR列にあることがわかりました。

次のようなものを探しています：

中国語を使用している場合-＆gt; NVARCHARを使用
ドイツ語とアラビア語がある場合-＆gt; NVARCHARを使用

サーバー/データベースの照合はどうですか？

ここで提案されているように常にNVARCHARを使用したくない SQL Serverデータ型varcharとnvarcharの主なパフォーマンスの違いは何ですか？

解決

NVARCHARを使用する本当の理由は、同じ列に異なる言語がある場合、デコードせずにT-SQLで列をアドレス指定する必要がある場合、「自然に」データSSMSで、またはUnicodeで標準化する場合。

データベースをダムストレージとして扱う場合、ワイド文字列と異なる（可変長であっても）エンコーディングをVARCHAR（たとえばUTF-8）に保存することは完全に可能です。問題は、特にコードページが行ごとに異なる場合に、エンコードおよびデコードしようとするときに発生します。また、SQL Serverは（潜在的に可変の）エンコードされた列に対してT-SQL内でクエリを実行する目的でデータを簡単に処理できないことを意味します。

NVARCHARを使用すると、このすべてが回避されます。

比較的制約の少ないユーザー入力データが含まれる列には、NVARCHARをお勧めします。

通常、標準または法律によって定義および制約されている自然なキー（車両のナンバープレート、SSN、シリアル番号、サービスタグ、注文番号、空港コールサインなど）である列にはVARCHARをお勧めしますコンベンション。また、ユーザーが入力した非常に制約された（電話番号など）またはコード（ACTIVE / CLOSED、Y / N、M / F、M / S / D / Wなど）のVARCHAR。それらにNVARCHARを使用する理由はまったくありません。

したがって、単純なルールの場合：

制約が保証されている場合の

VARCHAR それ以外の場合はNVARCHAR

他のヒント

複数の言語を保存する必要があるときはいつでもNVARCHARを使用する必要があります。アジア言語に使用する必要があると思いますが、引用してはいけません。

たとえばロシア語をvarcharに格納する場合の問題は、正しいコードページを定義する限り問題ありません。しかし、デフォルトの英語のSQLインストールを使用すると、ロシア語の文字は正しく処理されません。 NVARCHAR（）を使用している場合、それらは適切に処理されます。

編集

OK MSDN を引用させてください。特定ですが、varcar列に複数のコードページを格納する必要はありませんが、できません

次のようなテキストデータを扱う場合 char、varchar、 varchar（max）、またはテキストデータ型、考慮すべき最も重要な制限単一のコードページはシステム。（からデータを保存できます複数のコードページですが、これはそうではありません推奨）使用されている正確なコードページデータを検証および保存するには列の照合について。もし列レベルの照合はされていません定義済み、データベースの照合使用されている。コードページを決定するには特定の列に使用される場合、 COLLATIONPROPERTYを使用できます次のように機能しますコード例：

さらにいくつかあります：

この例は、グルジア語などの多くのロケールヒンディー語、コードページはありません。 Unicodeのみの照合です。それら照合は適切ではありません char、varchar、またはを使用する列テキストデータ型

したがって、グルジア語またはヒンディー語は、nvarcharとして保存する必要があります。アラビア語も問題です：

あなたが遭遇するかもしれない別の問題はそうでない場合にデータを保存できないあなたが望むすべてのキャラクターサポートはコードに含まれていますページ。多くの場合、Windowsは考慮します特定のコードページが＆quot; best フィット＆quot;コードページ、つまり信頼できるという保証はありませんすべてのテキストを処理するコードページ。それは単に利用可能な最高のもの。あこの例はアラビア語のスクリプトです：幅広い言語をサポートしているため、バルチ、ベルベル、ペルシア語、カシミール、カザフ、キルギス、パシュトウ、シンド語、ウイグル語、ウルドゥー語など。すべてのこれらの言語には追加のアラビア語の文字を超える文字 Windowsコードで定義されている言語 1256ページ。保存しようとした場合これらの余分な文字はアラビア語を含む非ユニコード列照合、文字は疑問符に変換されます。

Unicodeを使用している場合に留意すべき点がありますが、1つの列に異なる言語を格納できますが、1つの照合順序のみを使用して並べ替えることができます。ラテン文字を使用しているが、他のラテン言語のように分類されない言語がいくつかあります。アクセントはこの良い例です。例を思い出すことはできませんが、Yが英語のYのようにソートされなかった東ヨーロッパ言語がありました。その後、スペイン語のユーザーはhの後にソートされることを期待します。 / p>

インターナショナライゼーションを扱う際に対処しなければならないすべての問題をすべてまとめて。私の意見では、最初からユニコード文字を使用し、余分な変換を避け、スペースをヒットする方が簡単です。したがって、以前の私の声明。

ギリシャ語は、N列タイプのUTF-8が必要です：＆＃945;＆＃946;＆＃947; ;）

ジョシュは言う：＆quot; .... Unicodeを使用している場合に留意すべきことラテン文字を使用しているが、他のラテン言語のように分類されない言語がいくつかあります。アクセントはこの良い例です。例を思い出すことはできませんが、Yが英語のYのようにソートされていない東ヨーロッパの言語がありました。 ;

私はスペイン語を母国語としており、「ch」は文字ではなく、2つの「c」です。および「h」スペイン語のアルファベットは次のようなものです。 abcdefghijklmn＆＃241; opqrstuvwxyz 「ch」は期待していません。＆quot; h＆quot;の後しかし、「i」アルファベットは＆＃241;を除いて英語と同じです。またはHTMLで＆quot;＆amp; ntilde;＆quot;

アレックス

TL; DR;
Unicode-（nchar、nvarchar、およびntext）
非ユニコード-（char、varchar、およびtext）。

MSDNから

SQL Serverの照合順序は、並べ替え規則、大文字と小文字、およびアクセントを提供しますデータの感度プロパティ。使用される照合 charやvarcharなどの文字データ型がコードページを決定しますそのデータに対して表現できる対応する文字タイプ。

デフォルトのSQL照合 SQL_Latin1_General_CP1_CI_AS を使用していると仮定すると、次のスクリプトは1文字を格納するために1バイトを使用するため、 VARCHAR に収まるすべてのシンボルを印刷する必要があります（合計256）印刷されたリストに表示されない場合- NVARCHAR が必要です。

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

照合順序を日本語に変更すると、すべての奇妙なヨーロッパ文字が通常になり、一部の記号が？マークになります。

Unicodeは、コードポイントを文字にマッピングするための標準です。なぜならそれはのすべての言語のすべての文字をカバーするように設計されています世界では、異なるコードページが異なるを処理する必要はありません文字のセット。複数を反映する文字データを保存する場合言語、常にUnicodeデータ型（nchar、nvarchar、ntext）を使用します非Unicodeデータ型（char、varchar、およびtext）の代わりに。

そうしないと、ソートがおかしくなります。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow