Quando devemos usar NVARCHAR / NCHAR em vez de VARCHAR / CHAR no SQL Server?

Question

Existe uma regra em que devemos usar os tipos Unicode?

Eu vi que a maioria das línguas europeias (alemão, italiano, inglês, ...) são muito bem no mesmo banco de dados em colunas VARCHAR.

Eu estou procurando algo como:

1. Se você tiver chinês -> uso NVARCHAR
2. Se você tiver alemão e árabe -> uso NVARCHAR

E sobre o agrupamento do servidor / banco de dados?

Eu não quero sempre usar NVARCHAR como sugerido aqui Quais são as principais diferenças de desempenho entre varchar e nvarchar tipos de dados do SQL Server?

Answer 1

A verdadeira razão que deseja usar NVARCHAR é quando você tem diferente idiomas na mesma coluna, você precisa lidar com as colunas em T-SQL sem decodificação, você quer ser capaz de ver o dados "nativamente" em SSMS, ou você quer padronizar em Unicode.

Se você tratar o banco de dados como armazenamento mudo, é perfeitamente possível armazenar cadeias de largura e diferentes (mesmo de comprimento variável) codificações em VARCHAR (por exemplo, UTF-8). O problema surge quando você está tentando codificar e decodificar, especialmente se a página de código é diferente para diferentes linhas. Isso também significa que o SQL Server não será capaz de lidar com os dados facilmente para fins de consulta dentro de T-SQL em (potencialmente variável) colunas codificados.

Usando NVARCHAR evita tudo isso.

Eu recomendaria NVARCHAR para qualquer coluna que terá dados introduzidos pelo utilizador em que ela é relativamente sem restrições.

Eu recomendaria VARCHAR para qualquer coluna que é uma chave natural (como uma matrícula do veículo, CPF, número de série, marca de serviço, número de ordem, indicativo aeroporto, etc) que normalmente é definido e limitado por uma norma ou legislação ou convenção. Também VARCHAR para, e muito restrita (como um número de telefone) introduzidos pelo utilizador ou um código (ACTIVA / FECHADO, Y / N, M / F, H / S / D / W, etc). Não há absolutamente nenhuma razão para usar NVARCHAR para aqueles.

Assim, para uma regra simples:

VARCHAR quando garantida a ser condicionada NVARCHAR caso contrário

Answer 2

Você deve usar NVARCHAR quando você tem para armazenar vários idiomas. Eu acredito que você tem que usá-lo para os idiomas asiáticos, mas não citar-me sobre ele.

Aqui está o problema, se você tomar russo por exemplo, e armazená-lo em um varchar, você vai ficar bem, desde que você definir a página de código correto. Mas digamos que a sua utilização instalar um sql Inglês padrão, em seguida, os caracteres russos não será manuseado corretamente. Se você estivesse usando NVARCHAR () seriam tratadas adequadamente.

Editar

Ok, deixe-me citar MSDN e maybee eu estava a específico, mas você não deseja armazenar mais de uma página de código em uma coluna varcar, enquanto puder você não deve

Quando você lida com dados de texto que é armazenado no CHAR, VARCHAR, varchar (max), ou o tipo de dados de texto, o mais limitação importante considerar é que apenas informação de um único página de código pode ser validado pelo sistema. (Você pode armazenar dados de várias páginas de código, mas isso não é recomendado.) A página de código exato usado para validar e armazenar os dados depende no agrupamento da coluna. Se um -Nível coluna agrupamento não tem sido definido, o agrupamento do banco de dados é usado. Para determinar a página de código que é usado para uma determinada coluna, você pode usar o COLLATIONPROPERTY função, como mostrado no seguinte exemplos de código:

Aqui está um pouco mais:

Este exemplo ilustra o fato de que muitos locais, tais como Geórgia e Hindi, não tem páginas de código, como eles são Unicode somente agrupamentos. Essa agrupamentos não são apropriados para colunas que utilizam o CHAR, VARCHAR, ou Tipo de dados de texto

Então, Georgiano ou Hindi realmente precisam ser armazenados como nvarchar. O árabe é também um problema:

Outro problema que você pode encontrar é a incapacidade de armazenar dados quando não todos os caracteres que você deseja suporte estão contidos no código página. Em muitos casos, o Windows considera uma página de código especial para ser um "melhor fit" página de código, o que significa que há nenhuma garantia de que você pode contar com a página de código para lidar com todo o texto; isto é simplesmente o melhor disponível. A exemplo disso é o roteiro árabe: ele suporta uma grande variedade de línguas, Incluindo Baluchi, berbere, persa, Kashmiri, cazaque, quirguiz, pashto, Sindi, Uighur, Urdu, e muito mais. Tudo de línguas têm adicional caracteres além daqueles em árabe linguagem como definido no código do Windows Página 1256. Se você tentar loja esses caracteres extras em um coluna não Unicode que tem o árabe agrupamento, os personagens são convertidos em pontos de interrogação.

Algo para se manter em mente quando você estiver usando Unicode embora você pode armazenar diferentes idiomas em uma única coluna só pode classificar usando um único agrupamento. Existem alguns idiomas que usam caracteres latinos, mas não são classificadas como outras línguas latinas. Acentos é um bom exemplo disso, eu não posso recordar o exemplo, mas não havia uma língua do leste europeu cujo Y não fez classificar como o Y. Inglês Depois, há o ch espanhola que os usuários espanhol expet a ser classificado após h.

Ao todo, com todos os problemas que você tem que lidar com quando se lida com internalitionalization. É minha opinião que é mais fácil simplesmente usar caracteres Unicode desde o início, evitar as conversões extras e tomar o hit espaço. Daí a minha afirmação anterior.

Answer 3

grego seria necessário UTF-8 sobre os tipos de coluna N: aß?;)

Answer 4

Josh diz: " .... Algo para se manter em mente quando você estiver usando Unicode embora você pode armazenar diferentes idiomas em uma única coluna só pode classificar usando um único agrupamento. Existem alguns idiomas que usam caracteres latinos, mas não são classificadas como outras línguas latinas . Acentos é um bom exemplo disso, eu não posso lembrar-se é o exemplo, mas não havia uma língua do leste europeu cujo Y não fez classificar como o Y. Inglês depois, há o ch espanhola que os usuários espanhol expet a ser classificado após h. "

Eu sou um falante nativo de espanhol e "ch" não é uma carta, mas dois "c" e "h" eo alfabeto espanhol é como: abcdefghijklmn ± opqrstuvwxyz Nós não esperamos "ch" depois de "h", mas "i" O alfabeto é o mesmo que em Inglês, exceto para a N ou em HTML "Ñ"

Alex

Answer 5

TL; DR;
Unicode - (nchar, nvarchar e ntext)
Não-unicode -. (Char, varchar e texto)

De MSDN

Collations em SQL Server fornecem regras de classificação, caso, e sotaque propriedades de sensibilidade para seus dados. Agrupamentos que são usados ??com tipos de dados de caracteres como char e varchar ditar a página de código e caracteres que podem ser representados para que os dados correspondentes tipo.

Assumindo que você está usando padrão SQL agrupamento SQL_Latin1_General_CP1_CI_AS então seguinte script deve imprimir todos os símbolos que você pode caber em VARCHAR uma vez que utiliza um byte para armazenar um caractere (total 256), se você não vê-lo na lista impressa - você precisa NVARCHAR.

declare @i int = 0;
while (@i < 256)
begin
print cast(@i as varchar(3)) + '  '+  char(@i)  collate SQL_Latin1_General_CP1_CI_AS 
print cast(@i as varchar(3)) + '  '+ char(@i)  collate Japanese_90_CI_AS  
set @i = @i+1;
end

Se você mudar de intercalação a deixa japoneses dizem que você vai notar que todas as letras europeus estranhas transformou em normal e alguns símbolos para marcas ?.

Unicode é um padrão para mapear pontos de código de caracteres. Porque ele é projetado para cobrir todos os caracteres de todas as línguas da mundo, não há necessidade de diferentes páginas de código para lidar com diferentes conjuntos de caracteres. Se você armazenar dados de caracteres que reflete múltipla línguas, sempre use tipos de dados Unicode (nchar, nvarchar e ntext) em vez dos tipos não-Unicode de dados (CHAR, VARCHAR, e texto).

Caso contrário, sua classificação vai estranho.