現在、SQL Server 2012データベースではvarchar
を使用していますが、nvarchar
を変更します。そのためのスクリプトを生成しました。
SQL Serverがvarchar
列とnvarchar
列に書き込む方法に違いはありますか?私が心配しているバックエンド手順がいくつかあります。
編集:
これが役立つかどうかはわかりませんが、列にはインデックス、f/k、またはそれらに対する制約がありません。
Unicode文字列リテラルの前には必ずNプレフィックスを付ける必要があります。たとえば、基になるデータタイプがNVARCHAR
の場合、これらは異なる動作をします。
CREATE TABLE dbo.t(c NVARCHAR(32));
INSERT dbo.t(c) SELECT 'រៀន';
INSERT dbo.t(c) SELECT 'នរៀ';
INSERT dbo.t(c) SELECT N'រៀន';
SELECT c FROM dbo.t;
SELECT c FROM dbo.t WHERE c = 'រៀន';
SELECT c FROM dbo.t WHERE c = N'រៀន';
結果:
c
----
??? -- not stored correctly
??? -- not stored correctly
រៀន -- stored correctly!
c
----
???
??? -- probably not expected, however all Unicode characters have been changed to ?
c
----
រៀន
実際のUnicode文字ではなくボックス文字を表示するモバイルデバイスまたは老朽化したブラウザーのユーザーの場合、次のようになります。
最大の懸念は、nvarchar
が文字あたり2バイトを使用するのに対し、varchar
は1バイトを使用することです。したがって、nvarchar(4000)
はvarchar(8000)
*と同じ量のストレージ領域を使用します。
2倍のストレージ容量を必要とするすべてのキャラクターデータに加えて、これは次のことも意味します。
nvarchar
列を使用する必要がある場合があります。nvarchar(max)
列を使用している場合、varchar(max)
よりも早く列外にプッシュされます。nvarchar
列を使用する必要がある場合があります(このような大きなインデックスキーを使用する理由はわかりませんが、わかりません)。その上、クライアントソフトウェアがUnicodeを処理するように構築されていると仮定すると、nvarchar
の操作はそれほど変わりません。 SQL Serverはvarchar
をnvarchar
に透過的にアップコンバートするため、リテラルで2バイト文字(つまりUnicode)を使用している場合を除き、文字列リテラルにNプレフィックスを厳密に必要としません。 nvarchar
をvarbinary
にキャストすると、varchar
で同じことを行う場合とは異なる結果になることに注意してください。重要な点は、アプリケーションを動作させ続けるために、すべてのvarcharリテラルをすぐにnvarcharリテラルに変更する必要がないことです。これにより、プロセスが簡単になります。
*データ圧縮を使用する場合(軽量の行圧縮で十分で、Enterprise Editionが必要SQL Server 2016 SP1より前)通常、nchar
とnvarchar
には nicode圧縮(SCSUアルゴリズムを使用) のため、char
およびvarchar
よりも多くのスペース。
主な違いは次のとおりです。
nvarcharは、モバイルDBからSQL Server 2005へのRDPマージレプリケーションに必要でした。また、LTrim()、RTrim()、およびTrim()が頻繁に使用されました。 。
近年変更されたかどうかはわかりませんが、nvarcharは、生成されたデータベースで使用されるVS Pro 2017での.NET Simple Membership Webサイトログインに使用される標準になりました。