varcharとnvarcharの違いは何ですか？
nvarcharがマルチバイト文字をサポートしているということだけですか？その場合、ストレージの問題以外にvarcharsを使用することに本当に意味があるのでしょうか。
nvarchar列は、任意のUnicodeデータを格納できます。 varchar列は8ビットコードページに制限されています。 varcharはスペースを取らないので使うべきだと考える人もいます。これは正しい答えではないと思います。コードページの非互換性は問題であり、Unicodeはコードページの問題を解決するものです。最近の安価なディスクとメモリでは、コードページを使って時間を無駄にする必要はもうありません。
最近のすべてのオペレーティングシステムと開発プラットフォームは、内部でUnicodeを使用しています。 nvarcharではなくvarcharを使用すると、データベースから読み書きするたびにエンコード変換を行わなくて済みます。変換には時間がかかり、エラーが発生しやすいです。そして変換エラーからの回復はささいな問題です。
あなたがASCIIだけを使用するアプリケーションとインターフェースしているならば、私はまだデータベースでUnicodeを使用することをお勧めします。 OSとデータベースの照合アルゴリズムは、Unicodeの方がうまく機能します。 Unicodeは、他のシステムとインタフェースするときに変換の問題を回避します。そして、あなたは未来のために準備するでしょう。また、フルUnicodeストレージの利点を享受しながら、維持しなければならない従来のシステムに関係なく、データが7ビットASCIIに制限されていることを常に検証できます。
私が構築しているものはすべて、私がそれに投げるデータにほとんど耐えることができるので、私は常にnvarcharを使用します。私はnvarcharを使用したため、私のCMSシステムは誤って中国語を処理します。最近では、新しいアプリケーションが実際に必要なスペースの量を気にする必要はありません。
Oracleのインストール方法によって異なります。インストール処理中に、NLS_CHARACTERSETオプションが設定されます。あなたはそれをクエリSELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET'で見つけることができるかもしれません。
あなたのNLS_CHARACTERSETがUTF8のようなUnicodeエンコーディングであるなら、素晴らしいです。 VARCHARとNVARCHARの使用はほとんど同じです。今読むのをやめなさい、ただそれのために行きなさい。それ以外の場合、またはOracleのキャラクタ・セットを制御できない場合は、次に進んでください。
VARCHAR - データはNLS_CHARACTERSETエンコーディングで格納されます。同じサーバー上に他のデータベースインスタンスがある場合は、それらによって制限される可能性があります。設定を共有する必要があるので、その逆も同様です。 このようなフィールドには、その文字セットを使用してエンコードできるすべてのデータを格納できますが、それ以外は格納できません。たとえば、文字セットがMS-1252の場合、保存できるのは英語の文字、一握りのアクセントのある文字、その他の少数の文字（€や - など）だけです。あなたのアプリケーションは、世界中の他の場所で操作することができない、少数のロケールにのみ有用でしょう。このため、それは悪い考えと考えられています。
NVARCHAR - データはUnicodeエンコーディングで格納されています。すべての言語がサポートされています。良いアイデアです。
収納スペースはどうですか？ VARCHARは一般的に効率的です。文字セット/エンコードは特定のロケール用にカスタム設計されているからです。 NVARCHARフィールドは、皮肉なことに十分なNLS設定に基づいて、UTF-8またはUTF-16エンコーディングで格納します。 UTF-8は "西洋"言語には非常に効率的ですが、それでもアジア言語をサポートしています。 UTF-16はアジア言語には非常に効率的ですが、それでも「西洋」言語をサポートします。記憶領域を気にする場合は、OracleでUTF-8またはUTF-16を適切に使用するようにNLS設定を選択してください。
処理速度はどうですか？ほとんどの新しいコーディングプラットフォームではUnicodeがネイティブに使用されているため（Java、.NET、数年前のC++ std :: wstringでさえ！）、データベースフィールドがVARCHARの場合、読み書きごとに文字セット間の変換が強制されます。 NVARCHARを使用すると、変換が回避されます。
結論：NVARCHARを使用してください。制限や依存関係を避け、ストレージスペースには最適で、通常はパフォーマンスにも最適です。
nvarcharはデータをUnicodeとして格納するため、多言語データ（複数の言語）をデータ列に格納する場合は、Nというバリアントが必要です。
私の2セント
正しいデータ型を使用しないと、インデックスが失敗する可能性があります。
SQL Serverの場合：VARCHAR列の上に索引があり、それにUnicodeストリングを提示すると、SQL Serverはその索引を使用しません。 SmallIntを含むインデックス付きカラムにBigIntを提示したときにも同じことが起こります。 BigIntがSmallIntになるのに十分小さい場合でも、SQL Serverはインデックスを使用できません。他の方法では、この問題は起こりません（SmallIntまたはAnsi-Codeをインデックス付きBigIntまたはNVARCHAR列に提供する場合）。データ型はDBMS（データベース管理システム）によって異なります。
すべてのデータベースにはわずかに異なるデータ型があり、VARCHARはどこでも同じ意味ではありません。 SQL ServerにはVARCHARとNVARCHARがありますが、Apache/DerbyデータベースにはVARCHARしかなく、VARCHARはUnicodeです。
主にnvarcharはUnicode文字を格納し、varcharはUnicode以外の文字を格納します。
「Unicode」とは、アラビア語、ヘブライ語、中国語、日本語など、他の多くの言語の文字を単一の文字セットにエンコードできる16ビット文字エンコード方式を意味します。
つまり、unicodeは1文字あたり2バイトを使用して格納し、nonunicodeは1文字あたり1バイトを使用して格納します。つまり、Unicodeでは、Unicodeに比べて2倍の容量の保存が必要です。
私は言うだろう、それは異なります。
OSがUnicode（現在のすべてのWindowsシステムと同様に）で動作し、言語がネイティブにUnicodeをサポートするデスクトップアプリケーション（デフォルトの文字列はJavaやC＃のようにUnicode）を開発する場合は、nvarcharを使用してください。
文字列がUTF-8で、言語がPHPで、まだネイティブにUnicodeをサポートしていない（バージョン5.x）Webアプリケーションを開発する場合は、おそらくvarcharがより良い選択でしょう。
あなたが正しい。 nvarcharはUnicodeデータを格納し、varcharはシングルバイト文字データを格納します。すでに述べたように、ストレージの違い（nvarcharにはvarcharの2倍のストレージ容量が必要です）を除いて、nvarcharよりvarcharを好む主な理由は国際化です（つまり他の言語での文字列の保存）。
NVARCHARにはUnicodeが格納されていますが、照合の助けを借りてVARCHARを使用してローカル言語のデータを保存することもできます。
次のシナリオを想像してください。
DBの照合順序はペルシャ語であり、VARCHAR(10)データ型に 'علی'（ペルシャ語でのALiの書き込み）のような値を保存します。問題はなく、DBMSはそれを格納するのに3バイトしか使用しません。
ただし、データを別のデータベースに転送して正しい結果を確認する場合は、この例では、宛先データベースにターゲットと同じ照合順序を設定する必要があります。
ターゲットの照合順序が異なる場合は、ターゲットデータベースに疑問符（？）が表示されます。
最後に、あなたがあなたの地元の言語の使用のためである巨大なデータベースを使っているならば、私はあまりにも多くのスペースを使う代わりに位置を使うことを勧めます。
私はデザインが異なる可能性があると思います。作業環境によって異なります。
1バイトを使用して文字を格納する場合は、256通りの組み合わせが考えられるため、256種類の文字を保存できます。照合は、文字とそれらが比較およびソートされる規則を定義するパターンです。
Latin2（ANSI）である1252が最も一般的です。シングルバイト文字セットでも、多くの言語で使用されているすべての文字を格納するには不十分です。たとえば、一部のアジア言語は何千もの文字を持っているため、1文字あたり2バイトを使用する必要があります。
Unicode規格
複数のコードページを使用するシステムがネットワークで使用されると、通信を管理することが難しくなります。物事を標準化するために、ISOとUnicodeのコンソーシアムはUnicodeを導入しました。 Unicodeは各文字を格納するために2バイトを使用します。つまり、65,536個の異なる文字を定義できるので、ほとんどすべての文字をUnicodeでカバーできます。 2台のコンピュータがUnicodeを使用している場合、すべてのシンボルは同じ方法で表され、変換は不要です。これがUnicodeの背後にある考え方です。
SQL Serverには、2種類の文字データ型があります。
- 非Unicode（char、varchar、およびtext）
- Unicode（nchar、nvarchar、およびntext）
複数の国の文字データを保存する必要がある場合は、常にUnicodeを使用してください。
nVarcharは、Unicode文字を格納するのに役立ちます。ローカライズされたデータを保存したい場合は、これが適しています。
私はここで言わなければなりません（私はたぶん奴隷解放に自分自身を開放するつもりであることを私は知っています！）、しかし確かにNVARCHARname__が実際にmore役に立つときだけmorethere！）がVARCHARname__よりも、すべての依存システム上およびデータベース内のすべての照合順序が同じであることに注意してください。そうでなければ、照合変換はとにかく起こらなければならないのでVARCHARname__をNVARCHARname__と同じくらい実行可能にします。
これに加えて、 SQL Server（2012より前） などの一部のデータベースシステムでは、ページサイズが約10になっています。 8Kそのため、TEXTname__やNTEXTname__フィールドのようなものに保持されていない検索可能なデータを格納することを検討している場合、VARCHARname__は8kの全容量を提供しますが、NVARCHARname__は4kを提供します。
要約すると、どちらを使用するかは次の要素に依存します。
- プロジェクトまたは状況
- インフラ
- データベースシステム
私は答えを見ましたが、多くの人はnvarcharの代わりにvarcharを使うことを推奨しているようです。なぜならスペースはもう問題にならないからです。列にインデックスを適用したい場合は、必ずしもそうとは限りません。 SQL Serverでは、インデックスを付けることができるフィールドのサイズに900バイトの制限があります。それであなたがvarchar(900)を持っているなら、あなたはまだそれをインデックスすることができますがvarchar(901)はできません。 nvarcharでは、文字数が半分になるので、nvarchar(450)までインデックスを付けることができます。それであなたがnvarcharを必要としないと確信しているならば、私はそれを使うことを勧めません。
一般に、データベースでは、いつでも拡張できるので、必要なサイズに固執することをお勧めします。たとえば、職場の同僚は、ストレージに問題がないため、カラムにnvarchar(max)を使用しても問題ないと考えていました。後でこの列にインデックスを適用しようとしたときに、SQL Serverがこれを拒否しました。しかし、彼がvarchar(5)でさえ始めれば、この問題を解決するためにフィールドマイグレーション計画を行う必要があるような問題がない限り、後で必要なものに単純に拡張することができたでしょう。
FollowSql ServerのVARCHARデータ型とNVARCHARデータ型の違い。ここであなたは非常に説明的な方法で見ることができました。
一般に、nvarcharはデータをUnicodeとして格納するので、多言語データ（複数の言語）をデータ列に格納する場合は、Nというバリアントが必要です。
Varchar(n)とnvarchar(n)の主な違いは： 
Varchar（可変長、非Unicode文字データ）サイズは最大8000です。1.可変長データ型
非Unicode文字を格納するために使用されます
各文字に1バイトのスペースを占有します
Nvarchar：可変長Unicode文字データ.
1.可変長データ型です
2. Unicode文字を格納するために使用されます。
- データはUnicodeエンコーディングで保存されています。すべての言語がサポートされています。 （たとえば、アラビア語、ドイツ語、ヒンディー語などの言語）
〜47000の評判スコアを持つJeffrey L Whitledgeは、nvarcharの使用を推奨しています
〜33200の評判スコアを持つSolomon Rutzkyはお勧めします：常にNVARCHARを使用しないでください。それは非常に危険で、そしてしばしば高価な態度/アプローチです。
SQL Serverのvarcharデータ型とnvarcharデータ型の主なパフォーマンスの違いは何ですか？
https://www.sqlservercentral.com/articles/disk-is-cheap-orly-4
そのような高い評判の両方の人、学習SQL Serverデータベース開発者は何を選びますか？
選択に一貫性がないと、パフォーマンスの問題についての回答やコメントに多くの警告が表示されます。
パフォーマンス向上のためのコメントpro/con nvarcharがあります。
パフォーマンス向上のためのコメントpro/con varcharがあります。
何百もの列を持つテーブルに特別な要件がありますが、それ自体はおそらく珍しいでしょうか。
SQL * server 2012の8060バイトのテーブルレコードサイズの制限に近づかないように、varcharを選択しています。
私にとっては、nvarcharを使用すると、この8060バイトの制限を超えることになります。
また、関連するコードテーブルのデータ型をプライマリセントラルテーブルのデータ型と一致させる必要があるとも考えています。
南オーストラリア政府のこの作業場所で、経験豊富なデータベース開発者がvarchar列を使用したことがあります。テーブルの行数は数百万以上になります。そのため、予想されるデータ行数がこの決定の一部になる可能性があります。
nvarcharはUnicode文字も許可するため、varcharはnvarcharと比較して安全に使用でき、コードエラーを回避できます（型の不一致）。 SQL Serverクエリでwhere条件を使用していて、=演算子を使用している場合は、エラーが発生することがあります。これの考えられる理由は、マッピング列がvarcharで異なることです。これをnvarcharで定義しても、この問題は起こりません。それでも私たちはvarcharを守り、この問題を避けるために=よりもLIKEというキーワードを使用することをお勧めします。