Muitos dos meus bancos de dados têm campos definidos como varchars. Isso não tem sido um grande problema desde que moro e trabalho na América (onde a única língua que existe é "americano". ahem )
Depois de trabalhar com bancos de dados por cerca de 5 anos, descobri que eventualmente tive problemas com a natureza limitada do campo varchar e tive que modificar meus campos para armazenar dados como nvarchars. Depois de fazer outra atualização em uma tabela, convertendo um campo varchar em um nvarchar, pensei-- por que ainda estamos fazendo dessa maneira? Há muito tempo tomei a decisão mental de definir todos os meus novos campos de texto para nvarchar, em vez de varchar, que é o que aprendi a fazer em meus livros didáticos quando estava na escola, 10 anos atrás.
É 2011 e houve uma nova versão do SQL Server no ano passado. Por que continuamos a oferecer suporte a um tipo de dados varchar quando podemos/devemos usar nvarchar?
Eu sei que muitas vezes é argumentado que nvarchars são "duas vezes maiores" que varchars, então o uso do espaço de armazenamento pode ser um argumento para manter varcars.
No entanto, os usuários de hoje podem definir seus nvarchars para armazenar os dados como UTF-8 em vez do padrão UTF-16 se quiserem economizar espaço de armazenamento. Isso permitiria a codificação de 8 bits, se isso for principalmente desejável, ao mesmo tempo em que garante que o raro caractere de 2 a 8 bytes que é inserido em seu banco de dados não quebraria nada.
Estou esquecendo de algo? Existe uma boa razão para isso não ter mudado nos últimos 15-20 anos?
O trabalho varchar é bom o suficiente para muitos idiomas da Europa Ocidental (norueguês, dinamarquês, alemão, francês, holandês, etc.) sujeito a alguns problemas de agrupamento
Veja isso em SO varchar vs desempenho nvarchar nvarchar tem sérias implicações de desempenho
Isso é trivial comparado a lidar com datas MDY vs DMY
Além das respostas abordando padrões e compatibilidade, deve-se também ter em mente o desempenho. Embora o espaço em disco seja prontamente aceito como barato, os DBAs/desenvolvedores geralmente ignoram o fato de que o desempenho da consulta às vezes está diretamente relacionado ao tamanho da linha/página de uma tabela. Usar
NVARCHARem vez deVARCHAR(quando desnecessário) dobrará efetivamente o tamanho da linha para seus campos de caracteres. Se você tiver, digamos, 5 ou 10 campos de 50 comprimentos, está falando sobre a possibilidade de adicionar 500 bytes adicionais por linha. Se você tiver uma tabela grande, isso pode colocar cada linha em várias páginas e ter um efeito adverso no desempenho.Muitas organizações ainda possuem uma grande base instalada de aplicativos, interfaces, plataformas e ferramentas que assumem caracteres de byte único. Os bancos de dados raramente vivem isolados - eles são parte de um ecossistema de TI. Se você tiver milhares de componentes e milhões de linhas de código dependentes de caracteres de byte único, precisará de um bom motivo para investir o tempo e o dinheiro necessários para mudar para unicode. Mudanças nessa escala podem levar anos para serem concluídas. Em alguns lugares, o Unicode ainda é relativamente novo, raro ou sem suporte total.
VARCHAR e NVARCHAR fazem parte do SQL padrão ISO. Remover ou depreciar o suporte VARCHAR no SQL Server seria um retrocesso em compatibilidade e portabilidade.
Isso é exatamente o que a maioria dos bancos de dados de código aberto faz com
VARCHAR.utf8eucs2"agrupamentos".Não há necessidade de ter dois tipos de string separados.
A Microsoft é estranha com sua visão de que strings de 8 bits são para codificações herdadas e Unicode = UTF-16. O que provavelmente está relacionado à própria API do Windows tratando
charewchar_tdessa forma.Porque alguns de nós construímos aplicativos menores e mais leves em hardware menos avançado que não precisa de recursos Unicode. Talvez precisemos alterá-lo mais tarde, mas, por enquanto, simplesmente não precisamos disso. Eu gosto de minhas strings ocupando 1/2 do espaço que de outra forma teriam sob NVARCHAR.