Por que não usar SQL_Latin1_General_CI_AS para um sistema global?

Os agrupamentos no SQL Server lidam com vários aspectos dos dados de string:

1. Localidade/ LCID (referindo-se à Cultura: en-US, fr-FR, etc)

   Isso é usado para determinar substituições específicas de cultura para a classificação linguística padrão e regras de comparação usadas por Unicode / NVARCHARdados em todos os agrupamentos, bem como não-Unicode / VARCHARdados para Windows (ou seja, não- SQL_) agrupamentos.

2. Página de código

   Este é o conjunto de caracteres usado para não-Unicode/ VARCHARem todos os Collations. Para ser claro, as páginas de código não se aplicam a Unicode / NVARCHARdados, pois o Unicode é um conjunto de caracteres único. E, para ser bem claro, o Unicode é um único conjunto de caracteres, independentemente de como é codificado: UTF-8, UTF-16 ou UTF-32.

3. Sensibilidade

   A sensibilidade de maiúsculas e minúsculas e acentos pode ser controlada em todos os agrupamentos. A sensibilidade de Kana e Width só pode ser controlada ao usar os agrupamentos do Windows e é considerada "insensível" ao usar os SQL_agrupamentos.

   Além disso, todos os agrupamentos do Windows devem ter uma opção binária (pelo menos o obsoleto _BIN, se não também _BIN2), enquanto existem apenas dois SQL_agrupamentos que têm as opções _BIN/ _BIN2: SQL_Latin1_General_CP850e SQL_Latin1_General_CP437.

4. Capacidade de lidar com caracteres suplementares

   Um conjunto de Collations com nomes terminando em _SCfoi adicionado no SQL Server 2012. Eles permitem a classificação/comparação adequada, bem como o manuseio por funções internas para UTF-16 Surrogate Pairs (que é como o UTF-16 codifica pontos de código acima de U+ PFFF). Esta opção não está disponível para nenhum dos SQL_Agrupamentos.

   Observe que, independentemente do agrupamento, todos os dados UTF-16 podem ser armazenados e recuperados sem qualquer perda de dados em NVARCHAR/ NCHAR/ XMLcolunas e variáveis, mesmo que o agrupamento não permita a interpretação adequada de caracteres suplementares.

Além disso, existem algumas diferenças de comportamento para não-Unicode/ VARCHARdados somente ao usar SQL_Collations:

1. O valor ASCII 0 / CHAR(0)não equivale a uma string vazia.
2. Ao classificar dados usando um Collation com distinção entre maiúsculas e minúsculas (por exemplo SQL_Latin1_General_CP1_CS_AS, ), os caracteres maiúsculos serão classificados antes dos caracteres minúsculos.
3. String-sort é usado, que classifica toda a pontuação antes de todas as letras, em vez de Word-sort, que ignora hífens e apóstrofos dentro das palavras (por exemplo , a-fclassifica antes aade usar String-sort, mas depois quando usa Word-sort).
4. Nenhuma expansão de personagem específica da cultura é feita (por exemplo 'æ' = 'ae')

Há, no entanto, consistência comportamental entre NVARCHARos dados que usam qualquer agrupamento e VARCHARos dados que usam um agrupamento do Windows.

Portanto, idealmente, os SQL_Collations não devem ser usados ​​dadas as restrições e diferenças acima, sem mencionar que eles também estão obsoletos (e existem apenas 77 deles e 3810 Windows Collations no SQL Server 2014). Se for o caso, tente usar a versão mais recente de um Collation específico (por exemplo _100_, ) e, se oferecido, use uma terminação em _SC.

Infelizmente, SQL_Latin1_General_CP1_CI_ASé o padrão ao instalar uma nova instância nos EUA (pelo menos). Mas não se deve escolher voluntariamente um SQL_Collation para um novo desenvolvimento, especialmente quando é necessário lidar com várias culturas.

Mas para responder às 4 perguntas adicionais:

1. Como Japanese_CI_AS é diferente de SQL_Latin1_General_CI_AS quando se trata de classificar caracteres não japoneses?

   Isso é NVARCHARapenas com relação aos dados, certo? O LCID determina quais substituições específicas de cultura aplicar às opções de classificação padrão. Suspeito que os caracteres do inglês dos EUA classificarão o mesmo entre os agrupamentos japonês e latino1, mas não tenho certeza se isso vale para outros idiomas que também usam esses caracteres ou para caracteres não encontrados no inglês dos EUA, como letras com acentos. E uma complicação adicional é que você já tem as duas letras com acentos e, em seguida, letras sem os acentos combinadas apenas com os acentos (ou seja, combinando caracteres) e essas coisas podem não ser iguais nas localidades inglês/alemão/japonês/chinês.

2. O UCA é classificado de forma diferente de Japanese_CI_AS e SQL_Latin1_General_CI_AS?

   Não tenho certeza se essa pergunta faz sentido. Há uma ordem de classificação padrão dada a todos os caracteres. Em seguida, cada localidade pode substituir (substituir ou remover) qualquer um desses padrões ou adicionar novas regras. Portanto, o UCA é o peso base dos caracteres, mas cada cultura pode se desviar desses padrões. Portanto, haverá uma grande quantidade de sobreposição nas regras, mas também uma grande quantidade de variação entre elas.

3. Qual é a prática padrão da indústria para sistemas usados ​​globalmente? (Por exemplo, o que Facebook, Twitter, Google, Flickr, Baidu ou Microsoft, IBM e SAP usam?)

   Não tenho certeza do que essas empresas fazem exatamente, mas duvido que sejam pré-indexadas com regras linguísticas específicas da cultura. Pelo menos não em TODOS os dados. A maioria dos sites solicita seu idioma preferido e pode usá-lo para lidar com alguns dos dados. De qualquer forma, não há como ter uma classificação única e verdadeiramente independente da cultura.

4. SQL_Latin1_General_CI_AS define uma ordem de classificação para caracteres japoneses? Se não, como/por que o texto em japonês funciona no SQL_Latin1_General_CI_AS?

   Não tenho certeza do que significa o texto em japonês "trabalhando", mas o Unicode é um conjunto de caracteres único para todos os idiomas. Assim, a capacidade de armazenar os caracteres de um determinado idioma não implica nas regras pelas quais esses caracteres serão classificados.

   Conforme mencionado acima, o UCA é uma ordem de classificação padrão para todos os caracteres. Os agrupamentos Latin1 podem fazer classificação básica em todos os idiomas (em termos de Unicode/ NVARCHARdados), mas teriam apenas as regras padrão. Os agrupamentos Latin1 não teriam nenhuma regra específica de cultura e pode haver vários conjuntos dessas regras. Além disso, conforme declarado acima, os SQL_Collations não têm a capacidade de ativar a sensibilidade Kana ou Width, que você pode precisar.

O roteiro a seguir deve deixar claro em relação à pergunta 1.

declare @i int = 0;
declare @temp table( id int, latin varchar(1) collate SQL_Latin1_General_CP1_CI_AS, jap varchar(1) collate Japanese_90_CI_AS )
while (@i < 256)
begin
insert into @temp 
select @i, char(@i)  collate SQL_Latin1_General_CP1_CI_AS ,char(@i)  collate Japanese_90_CI_AS  

set @i = @i+1;
end

select * from @temp
order by latin

select * from @temp
order by jap

2. Agrupamento são as regras sobre como classificar , leia sobre isso . O script acima deve mostrar como as alterações de classificação têm uma aparência de como ele corresponde ao UCA .

3. Qualquer resposta seria baseada em opinião, a maioria das empresas acima não usa um único tipo de banco de dados (gráfico, bigdata, etc.), nunca precisei usar nada além de SQL_Latin1_General_CP1_CI_AS. (Eu nunca tive que trabalhar fora da Europa éter)

4. Se você estiver usando nvarchars= você está usando unicodee unicode é como Chuck Norris - cobre tudo (duas vezes).