Por que ainda existe um tipo de dados varchar?

Muitos dos meus bancos de dados têm campos definidos como varchars. Isso não tem sido muito problemático desde que vivo e trabalho na América (onde o único idioma que existe é "americano". Ahem )

Depois de trabalhar com bancos de dados por aproximadamente 5 anos, descobri que acabei encontrando problemas com a natureza limitada do campo varchar e preciso modificar meus campos para armazenar dados como nvarchars. Depois de ter que fazer outra atualização em uma tabela, convertendo um campo varchar em um nvarchar, pensei: por que ainda estamos fazendo isso dessa maneira? Há muito que tomei a decisão mental de definir todos os novos campos de texto como nvarchar, em vez de varchar, que foi o que aprendi a fazer nos meus livros de texto quando estava na escola há 10 anos.

É 2011 e houve uma nova versão do SQL Server no ano passado. Por que continuamos a suportar um tipo de dados varchar quando podemos / devemos usar nvarchar?

Sei que muitas vezes se argumenta que os nvarchars são "duas vezes maiores" que os varchars; portanto, o uso do espaço de armazenamento pode ser um argumento para os principais varcars.

No entanto, os usuários de hoje podem definir seus nvarchars para armazenar os dados como UTF-8 em vez do UTF-16 padrão, se quiserem economizar espaço de armazenamento. Isso permitiria a codificação de 8 bits, se isso for principalmente desejável, enquanto garante que o caractere raro de 2 a 8 bytes inserido no banco de dados não quebraria nada.

Estou esquecendo de algo? Existe uma boa razão para que isso não tenha mudado nos últimos 15 a 20 anos?

1. O trabalho varchar é bom o suficiente para muitas línguas da Europa Ocidental (norueguês, dinamarquês, alemão, francês, holandês etc.), sujeito a alguns problemas de agrupamento

2. Veja isto no SO varchar vs nvarchar performance nvarchar tem implicações sérias no desempenho

3. Isso é trivial comparado a lidar com datas MDY vs DMY

Além das respostas sobre padrões e compatibilidade, é preciso também ter em mente o desempenho. Embora o espaço em disco seja facilmente 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 em NVARCHARvez de VARCHAR(quando desnecessário) dobrará efetivamente o tamanho da linha dos campos de seu personagem. Se você tem, digamos, 5 ou 10 campos de 50 comprimentos, está falando em adicionar potencialmente 500 bytes adicionais por linha. Se você tiver uma tabela ampla, isso poderá enviar cada linha para várias páginas e afetar adversamente o desempenho.

Muitas organizações ainda têm uma grande base instalada de aplicativos, interfaces, plataformas e ferramentas que assumem caracteres de byte único. Os bancos de dados raramente vivem isolados - fazem parte de um ecossistema de TI. Se você possui 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 o unicode. Mudanças nessa escala podem levar anos para serem concluídas. Em alguns lugares, o Unicode ainda é relativamente novo, raro ou não é totalmente suportado.

VARCHAR e NVARCHAR fazem parte do SQL Standard ISO. Remover ou descontinuar o suporte do VARCHAR no SQL Server seria um retrocesso na compatibilidade e portabilidade.

Como alternativa, os usuários de hoje podem definir seus nvarchars para armazenar os dados como UTF-8 em vez do UTF-16 padrão, se quiserem economizar espaço de armazenamento.

É exatamente o que a maioria dos bancos de dados de código aberto faz VARCHAR.

• O MySQL fornece utf8e ucs2"agrupamentos".
• O SQLite oferece uma escolha entre UTF-8 (o padrão) e UTF-16.
• O PostgreSQL suporta UTF-8 (mas não UTF-16).

Não é necessário ter dois tipos de string separados.

A Microsoft é estranha, considerando que as seqüências de 8 bits são para codificações herdadas e Unicode = UTF-16. O que provavelmente está relacionado ao próprio tratamento da API do Windows chare wchar_tdessa maneira.

Porque alguns de nós construímos aplicativos menores e mais leves em menos do que o hardware de última geração que não precisa de recursos Unicode. Talvez precisemos alterá-lo mais tarde, mas, por enquanto, simplesmente não precisamos. Gosto que minhas cordas ocupem metade do espaço que teriam em NVARCHAR.