新しい文字列カラムを定義するエンジニアは皆決断を迫られます：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は他のシステムとのインターフェース時の変換問題を回避します。そして将来に備えることができます。また、完全なUnicodeストレージの利点の一部を享受しながら、維持しなければならないレガシーシステムのためにデータが7ビットASCIIに制限されていることを常に検証できます。（2）
私の結論は、データがvarcharになるのは静止状態にあるときだけです。
参考文献:
1. Unicode Compression implementation
2. What is the difference between varchar and nvarchar?
著者：Chuck Conwayはソフトウェアエンジニアリングと生成AIを専門としています。ソーシャルメディアで彼とつながりましょう：X (@chuckconway) または YouTube をご覧ください。