NVarchar と Varchar の比較

新しい文字列列を定義するエンジニアは決断を迫られます：nvarchar を使うべきか、それとも varchar を使うべきか？

nvarchar を発見して以来、私は常に nvarchar を使用しています。私の考えは、テキスト値をサポートしない可能性があるデータ型を使用する理由は何か、そして互換性の問題は本番環境に入るまで発見されない可能性があるということです。

スペースについての議論を聞きますが、スペースは安価であり、心配する価値はありません。あなたが考えていることは分かります。ハードドライブがいっぱいになった場合、コストは関係ないということですね。同意します。

SQL Server 2008 R2 以降、データ圧縮は nchar および nvarchar（nvarchar(max) は除外）フィールドに適用されます。データによって圧縮の効果は異なりますが、英語の場合、50% の圧縮が実現され、これは varchar のスペース要件と同等になります（1）。

考慮すべき別の点は、ほとんどのプログラミング言語が UTF-16 を文字列型としてサポートしていることです。したがって、varchar がデータベースから読み込まれるたびに、UTF-16（nvarchar のような）に変換されます。

この StackOverflow の回答は nvarchar と varchar をまとめています：

nvarchar 列は任意の Unicode データを格納できます。varchar 列は 8 ビット コードページに制限されています。varchar はスペースが少なくて済むため使用すべきだと考える人もいます。これは正しい答えではないと私は考えます。コードページの非互換性は厄介であり、Unicode はコードページの問題の解決策です。最近のディスクとメモリが安価であることを考えると、コードページを扱うのに時間を浪費する理由は本当にありません。

すべての最新のオペレーティング システムと開発プラットフォームは、内部的に Unicode を使用しています。varchar ではなく nvarchar を使用することで、データベースから読み取るまたは書き込むたびにエンコーディング変換を行うことを回避できます。変換には時間がかかり、エラーが発生しやすいです。また、変換エラーからの回復は簡単な問題ではありません。

ASCII のみを使用するアプリケーションとインターフェースしている場合でも、データベースで Unicode を使用することをお勧めします。OS とデータベースの照合アルゴリズムは Unicode でより良く機能します。Unicode は他のシステムとのインターフェース時の変換の問題を回避します。そして、将来に向けて準備することができます。また、レガシー システムを維持する必要がある場合でも、データが 7 ビット ASCII に制限されていることを常に検証でき、完全な Unicode ストレージの利点の一部を享受できます。（2）

私の結論は、データが varchar である唯一の時間は、それが保存されている時です。

参考文献:

1. Unicode Compression implementation
2. What is the difference between varchar and nvarchar?