Ao contrário de alguns outros RDBMSs que permitem escolher uma codificação, o SQL Server armazena dados Unicode somente em UTF-16 (Little Endian) e dados não Unicode em uma codificação de 8 bits (Extended ASCII, DBCS ou EBCDIC) para qualquer página de código implícita no agrupamento do campo.

Sua decisão de escolher O UCS-2 faz sentido, já que o UTF-16 foi introduzido em meados de 1996 e totalmente especificado em 2000. Muitos outros sistemas também o usam (ou usaram) (consulte:https://en.wikipedia.org/wiki/UTF-16#Usage ). A decisão deles de continuar com ele pode ser mais questionável, embora seja provavelmente devido ao Windows e .NET serem UTF-16. O layout físico dos bytes é o mesmo entre UCS-2 e UTF-16, portanto, atualizar sistemas de UCS-2 para suportar UTF-16 deve ser puramente funcional, sem necessidade de alterar nenhum dado existente.

Não. Criar um tipo definido pelo usuário personalizado via SQLCLR não , de qualquer forma, vai te dar um substituto de qualquer tipo nativo. É muito útil para criar algo para lidar com dados especializados. Mas strings, mesmo de uma codificação diferente, estão longe de ser especializadas. Seguir esse caminho para seus dados de string destruiria qualquer quantidade de usabilidade do seu sistema, sem mencionar o desempenho, pois você não seria capaz de usar qualquer funções de string embutidas. Se você pudesse economizar qualquer coisa no espaço em disco, esses ganhos seriam apagados pelo que você perderia no desempenho geral. Armazenar um UDT é feito serializando-o para um VARBINARY . Então, para fazer qualquer comparação de strings OU classificação, fora de uma comparação "binária" / "ordinal", você teria que converter todos os outros valores, um por um, de volta para UTF-8 para fazer a comparação de strings que pode levar em conta as diferenças linguísticas.

Além disso, essa "documentação" é realmente apenas um código de amostra/prova de conceito. O código foi escrito em 2003 ( http://msftengprodsamples.codeplex.com/SourceControl/latest#Kilimanjaro_Trunk/Programmability/CLR/UTF8String/CS/UTF8String/Utf8String.cs ) para SQL Server 2005. Vi um script para testar a funcionalidade, mas nada envolvendo desempenho.

Sim muito mesmo. Por padrão, o manuseio das funções internas é apenas para UCS-2. Mas a partir do SQL Server 2012, você pode fazer com que eles lidem com o conjunto completo de caracteres UTF-16 (bem, a partir do Unicode versão 5 ou 6, dependendo do seu sistema operacional e versão do .NET Framework) usando um dos agrupamentos que tem um nome que termina em _SC (ou seja, caracteres suplementares).

Correto. UTF-16 e UCS-2 usam pontos de código de 2 bytes. Mas o UTF-16 usa alguns deles em pares (ou seja, pares substitutos) para mapear caracteres adicionais. Os pontos de código usados ​​para esses pares são reservados para essa finalidade no UCS-2 e, portanto, não são usados ​​para mapear para nenhum símbolo utilizável. É por isso que você pode armazenar qualquer caractere Unicode no SQL Server e ele será armazenado e recuperado corretamente.

Correto, embora enganoso. Sim, o UTF-8 é de largura variável, mas o UTF-16 também é pouco variável, pois todos os caracteres suplementares são compostos de dois pontos de código de byte duplo. Portanto, o UTF-16 usa 2 ou 4 bytes por símbolo, embora o UCS-2 seja sempre 2 bytes. Mas essa não é a parte enganosa. O que é enganoso é a implicação de que qualquer outra codificação Unicode não é capaz de codificar todos os outros pontos de código. Enquanto o UCS-2 pode mantê-los, mas não interpretá-los, tanto o UTF-16 quanto o UTF-32 podem mapear todos os pontos de código Unicode, assim como o UTF-8.

Isso pode ser verdade, mas é totalmente irrelevante do ponto de vista operacional.

Novamente, é verdade, mas totalmente irrelevante, pois UTF-16 e UTF-32 também mapeiam todos os pontos de código Unicode.

Dependendo das circunstâncias, isso pode muito bem ser verdade, e você está correto em se preocupar com esse uso inútil. No entanto, como mencionei na pergunta que levou a esta ( Suporte a UTF-8, SQL Server 2012 e UTF8String UDT ), você tem algumas opções para reduzir a quantidade de espaço desperdiçado se a maioria das linhas couber em VARCHAR ainda alguns precisam ser NVARCHAR . A melhor opção é habilitar ROW COMPRESSION ou PAGE COMPRESSION (somente Enterprise Edition!). A partir do SQL Server 2008 R2, eles permitem NVARCHAR não-MAX campos para usar o "Esquema de compactação padrão para Unicode", que é pelo menos tão bom quanto UTF-8 e, em alguns casos, é ainda melhor que UTF-8. NVARCHAR(MAX) campos não podem usar esta compressão sofisticada , mas seus dados IN ROW podem se beneficiar da compactação ROW e/ou PAGE regular. Consulte o seguinte para obter uma descrição dessa compactação e um gráfico comparando os tamanhos de dados para:UCS-2/UTF-16 bruto, UTF-8 e UCS-2/UTF-16 com compactação de dados habilitada.

SQL Server 2008 R2 - compressão UCS2 o que é - Impacto nos sistemas SAP

Consulte também a página do MSDN para Compactação de dados para mais detalhes, pois há algumas restrições (além de estar disponível apenas na Enterprise Edition -- MAS disponibilizado para todos edições começando com SQL Server 2016, SP1 !!) e algumas circunstâncias em que a compactação pode piorar as coisas.

A veracidade dessa afirmação depende de como se define "disco". Se você está falando em termos de peças de commodities que você pode comprar na prateleira de uma loja para usar em seu desktop / laptop, com certeza. Mas, se estiver falando em termos de armazenamento de nível empresarial que será usado para seus sistemas de produção, divirta-se explicando a quem controla o orçamento que eles não devem rejeitar a SAN de mais de um milhão de dólares que você deseja porque é "barata ";-).

Nenhum que eu possa pensar. Bem, contanto que você não siga nenhum conselho horrível para fazer algo como implementar esse UDT ou converter todas as strings para VARBINARY , ou usando NVARCHAR(MAX) para todos os campos de string;-). Mas de todas as coisas com as quais você pode se preocupar, o SQL Server usando UCS-2 / UTF-16 não deve ser uma delas.

Mas, se por algum motivo esse problema de falta de suporte nativo para UTF-8 for super importante, talvez seja necessário encontrar outro RDBMS para usar que permita UTF-8.

ATUALIZAÇÃO 2018-10-02

Embora ainda não seja uma opção viável, o SQL Server 2019 apresenta suporte nativo para UTF-8 em VARCHAR / CHAR tipos de dados. Atualmente, existem muitos bugs com ele para serem usados, mas se eles forem corrigidos, então esta é uma opção para alguns cenários. Por favor, veja minha postagem, "Suporte UTF-8 nativo no SQL Server 2019:Salvador ou Falso Profeta? ", para uma análise detalhada desta nova funcionalidade.