Escrever diferenças entre varchar e nvarchar

Você precisa ter certeza de prefixar os literais de string Unicode com um prefixo N. Por exemplo, eles funcionarão de maneira diferente se o tipo de dados subjacente for 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'រៀន';

Resultados:

c
----
??? -- not stored correctly
??? -- not stored correctly
រៀន -- stored correctly!

c
----
???
??? -- probably not expected, however all Unicode characters have been changed to ?

c
----
រៀន

Para aqueles em dispositivos móveis ou navegadores decrépitos que mostram caracteres de caixa em vez de caracteres Unicode reais, é assim:

A maior preocupação é que nvarcharusa 2 bytes por caractere, enquanto varcharusa 1. Assim, nvarchar(4000)usa a mesma quantidade de espaço de armazenamento que varchar(8000)*.

Além de todos os seus dados de personagem precisarem de duas vezes mais espaço de armazenamento, isso também significa:

• Você pode ter que usar nvarcharcolunas mais curtas para manter as linhas dentro do limite de linha de 8.060 bytes/limite de coluna de caracteres de 8.000 bytes.
• Se você estiver usando nvarchar(max)colunas, elas serão empurradas para fora da linha mais cedo do que varchar(max)seriam.
• Você pode ter que usar nvarcharcolunas mais curtas para ficar dentro do limite de chave de índice de 900 bytes (não sei por que você gostaria de usar uma chave de índice tão grande, mas nunca se sabe).

Além disso, trabalhar com nvarcharnão é muito diferente, supondo que seu software cliente seja construído para lidar com Unicode. O SQL Server converterá de forma transparente a varcharpara nvarchar, portanto, você não precisa estritamente do prefixo N para literais de string, a menos que esteja usando caracteres de 2 bytes (ou seja, Unicode) no literal. Esteja ciente de que lançar nvarcharpara varbinaryproduz resultados diferentes do que fazer o mesmo com varchar. O ponto importante é que você não precisará alterar imediatamente cada literal varchar para um literal nvarchar para manter o aplicativo funcionando, o que ajuda a facilitar o processo.

* Se você usar compactação de dados (a compactação de linha leve é ​​suficiente, Enterprise Edition necessária antes do SQL Server 2016 SP1 ), normalmente encontrará nchare nvarcharnão ocupará mais espaço do que chare varchar, devido à compactação Unicode (usando o algoritmo SCSU) .

Pense que as seguintes são as principais diferenças:

1. Nvarchar armazena dados UNICODE. Se você tiver requisitos para armazenar dados UNICODE ou multilíngues, nvarchar é a escolha. Varchar armazena dados ASCII e deve ser seu tipo de dados de escolha para uso normal.
2. Em relação ao uso de memória, nvarchar usa 2 bytes por caractere, enquanto varchar usa 1.
3. JOIN-ing um VARCHAR para NVARCHAR tem um impacto de desempenho considerável.
4. Pode precisar de um prefixo N quando insere dados: INSERT dbo.t(c) SELECT N'ʤ ʥ ʦ ʧ ʨ';
5. Alguns especialistas recomendam nvarchar sempre porque: como todos os sistemas operacionais modernos e plataformas de desenvolvimento usam Unicode internamente, usar nvarchar em vez de varchar evitará conversões de codificação toda vez que você ler ou gravar no banco de dados

nvarchar era necessário para replicação de mesclagem RDP de um banco de dados móvel para SQL Server 2005. Além disso, LTrim(), RTrim() e Trim() eram muito usados ​​porque nvarchar não cortava automaticamente os espaços da entrada de dados, enquanto o Varchar fazia .

Não sei se isso mudou nos últimos anos ou não, mas nvarchar agora é o padrão usado para logins do site de associação simples do .NET no VS Pro 2017 usado no banco de dados gerado.

Se você usar NVarchar sobre Varchar e não tiver requisito de suporte a MULTI-LINQUAL, aumentará o armazenamento para banco de dados, backups (locais e externos). Bancos de dados modernos devem oferecer suporte a ambos e quaisquer ocorrências de conversão devem ser consideradas no design.