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、そうでない場合はVARCHAR