Algum DBMS tem um agrupamento que diferencia maiúsculas de minúsculas e não diferencia acentos?

TL;DR

Não existe uma visão "agnóstica de fornecedor" de agrupamentos, nem mesmo "gnóstica de versão", uma vez que suas implementações - incluindo quais aspectos podem ser tornados insensíveis e suas convenções de nomenclatura - são específicas do fornecedor e mudam com o tempo .

Aqui está um resumo do que encontrei, e os detalhes estão na seção mais longa abaixo da linha:

RDBMS        Naming-             Combinations    Case-Sensitive and
             convention          of options?     Accent-Insensitive support?
-------      ------------        -------------   -----
SQL Server   _CS, _AI, etc       Yes             Latin1_General_100_CS_AI

DB2          _E{x}, _S{y}, etc   Yes             CLDR181_EO_S1

PostgreSQL   locale: en_US       N/A             unaccent(), not via Collation

MySQL        _cs, maybe _ai      No              No: _cs implies _as & _ci implies _ai
                                                 Yes? Create your own Collation :-)

Oracle       only _CI & _AI      No              No: _AI always implies _CI

SAP ASE      arbitrary: turdict  N/A             No: "AI" always implies "CI"

Informix     locale.codepage     N/A             No: no "AI" via Collations

Como você pode ver no gráfico, dois dos sete RDBMSs oferecem suporte nativo a operações "diferenciando maiúsculas de minúsculas e sem diferenciação de acentos" por meio de agrupamentos, embora tenham convenções de nomenclatura diferentes (e várias outras diferenças funcionais).

Um RDBMS -- PostgreSQL -- não oferece suporte nativo a essa combinação, mas você ainda pode obtê-la removendo os acentos com a unaccent()função complementar.

Os últimos quatro RDBMSs, dois dos quais têm uma convenção de nomenclatura semelhante para as opções, não oferecem suporte nativo a essa combinação nem parece haver um meio de fazer isso sem escrever sua própria função para remover os acentos/marcas diacríticas. O MySQL permite criar seus próprios agrupamentos, mas isso requer que você o adicione ao controle de origem e incorpore-o ao seu processo de teste e implantação para que possa ser aplicado a todos os servidores em todos os ambientes (mas ainda é uma opção muito legal e flexível) . O SAP ASE menciona que a SAP pode fornecer ordens de classificação Unicode adicionais, mas não menciona o que eles podem estar dispostos a fornecer.

Com relação a:

Existe uma boa razão para isso ou o meu é apenas um caso de uso raro?

Posso dizer que, ao fazer a pesquisa para esta resposta, encontrei muitos casos de pessoas que não diferenciam maiúsculas de minúsculas e diferenciam acentos para o MySQL, mas poucos, se houver, solicitando a combinação desejada.

Eu queria que uma condição de pesquisa usasse um agrupamento que diferenciasse maiúsculas de minúsculas, mas não diferenciasse acentos, mas não consegui encontrar um.
...
esta pergunta é independente de fornecedor/versão

Você não obteve sucesso em sua pesquisa porque realmente não faz sentido procurar um RDBMS baseado em uma especificação de Collation. Não é assim que os Collations funcionam. E embora você queira abordar isso como independente do fornecedor, a realidade é que os agrupamentos - pelo menos a parte com a qual interagimos - são muito específicos do fornecedor e nem sempre se encaixam no esquema que você estava procurando .

A comparação e a classificação de strings são altamente complexas e existem diferentes maneiras de executar essas regras. Um método é ter mapeamentos que levem em conta uma ou mais regras. Portanto, as quatro combinações de sensível e insensível para maiúsculas e minúsculas e acentos equivaleriam a quatro mapeamentos separados. Por exemplo, você viu isso na página do MSDN para SQL Server Collation Name . Se você rolar para baixo, verá que a coluna esquerda do gráfico é o Sort Order ID. Cada Collation tem um ID diferente: SQL_Latin1_General_Cp1_CI_AS= 52 while SQL_Latin1_General_Cp1_CS_AS= 51, embora a única diferença esteja na diferenciação de maiúsculas e minúsculas.

Ou pode ser baseado em regras, como o que o Unicode oferece por meio do Unicode Collation Algorithm (UCA). Nessa abordagem, cada caractere recebe, por padrão, um ou mais pesos. Em seguida, cada cultura/localidade tem a opção de substituir qualquer um desses pesos, remover regras ou adicionar regras. O algoritmo leva em consideração quaisquer regras específicas de localidade e, em seguida, potencialmente manipula esses pesos com base em quaisquer opções escolhidas (sensibilidade, qual maiúsculas e minúsculas vem primeiro ao fazer classificações com distinção entre maiúsculas e minúsculas, etc.). Esse é um dos motivos pelos quais a classificação Unicode é um pouco mais lenta do que a classificação não Unicode.

Para ter uma noção de quantas opções realmente existem (ou seja, a complexidade real), confira esta demonstração do projeto ICU (International Components for Unicode):

Demonstração de agrupamento de UTI

Existem 8 opções separadas para especificar, e algumas delas são representadas em vários elementos da especificação do nome do Collation que você está pensando (por exemplo CS, CI, AS, , AI, etc). Considerando quantas variações existem, usar a abordagem de arquivo de mapeamento em que cada combinação tem seu próprio ID resultaria em muitos milhares de arquivos. Muitos desses arquivos precisariam ser atualizados sempre que houvesse alterações nesses idiomas específicos ou quando fossem encontrados bugs. Provavelmente é por isso que existem apenas 75 desses tipos de agrupamentos no SQL Server 2012 (ou seja, aqueles com nomes começando com SQL_). Portanto, nenhuma combinação para _CS_AI.

E a razão pela qual você não conseguiu encontrar essa combinação para os Collations baseados em UCA? Bem, existem 3.810 agrupamentos no SQL Server 2012 que não começam com SQL_, portanto, 3.885 agrupamentos no total. Essa lista parece ser muito longa para ser enumerada completamente em uma página da web. Mas isso não explica totalmente por que você não conseguiu encontrar essa combinação para outros fornecedores.

Além do que já foi mencionado (ou seja, muitas combinações para implementar e muitas implementações para listar), você ainda precisa lidar com implementações específicas do fornecedor. Significado: nem todos os fornecedores permitem adaptar todas essas opções e, em primeiro lugar, não há convenção de nomenclatura padrão para Collations. Além disso, nem todos os fornecedores veem as opções de classificação como parte do Collation: PostgreSQL Collations são ordenações padrão para o local escolhido e você precisa usar ILIKEpara obter uma comparação que não diferencia maiúsculas de minúsculas. Veja abaixo as informações específicas do fornecedor.

Servidor SQL (Microsoft)

A distinção entre o que você está vendo nessas duas páginas de documentação do MSDN e a consulta fornecida por @MartinSmith em um comentário sobre a pergunta (ligeiramente revisado abaixo):

SELECT *
FROM   sys.fn_helpcollations()
WHERE  [name] LIKE '%[_]CS[_]AI%';

é que essas duas páginas do MSDN estão se referindo especificamente aos muito obsoletos agrupamentos do SQL Server, enquanto os agrupamentos que aparecem como resultado dessa consulta (888 deles no SQL Server 2012, SP3) são agrupamentos do Windows.

A partir do SQL Server 2000, os agrupamentos do SQL Server mais antigos (criados antes de o SQL Server ser capaz de acessar os agrupamentos do Windows) foram preteridos e não estão sendo atualizados com novas regras ou funcionalidades. Por exemplo, a partir do SQL Server 2012, foi adicionado um conjunto de agrupamentos que suportam o tratamento adequado das funções internas para caracteres suplementares (ou seja, os caracteres UTF-16 restantes além dos 65.536 caracteres "base" inicialmente definidos no UCS-2 ). Esses novos agrupamentos terminam em _SC(como em caracteres suplementares ) .

É melhor não usar agrupamentos do SQL Server - aqueles com nomes começando com SQL_. Portanto, você tem acesso a vários agrupamentos que suportam a combinação de opções que você está procurando (isto é, diferencia maiúsculas de minúsculas e não diferencia acentos). Sempre que disponível, também é melhor usar uma extremidade _SCdesde que tenha todas as outras opções que você deseja.

Embora o SQL Server use a _CS_AIconvenção de nomenclatura, não há uma lista de todos os agrupamentos do Windows 3810 (a partir do SQL Server 2012). Há apenas a página Windows Collation Name que lista todas as localidades e versões e como funciona a convenção de nomenclatura, mas é isso.

O SQL Server também dá suporte à alternância de sensibilidade de largura e Kana.

MySQL (comprado pela Oracle)

A documentação do MySQL versão 5.7 afirma que ele suporta os sufixos , , e (e _aipara _asintegridade _ci) , mas também afirma:_cs_bin

Para nomes de agrupamento não binários que não especificam a diferenciação de acentos, isso é determinado pela diferenciação de maiúsculas e minúsculas. Ou seja, se um nome de agrupamento não contiver _aiou _as, _cino nome implica _aie _csno nome implica _as.

Por exemplo, latin1_general_cinão diferencia maiúsculas de minúsculas (e não diferencia acentos, implicitamente), diferencia latin1_general_csmaiúsculas de minúsculas (e diferencia acentos, implicitamente)

Isso certamente implica que é possível ter um latin1_general_cs_aiCollation. No entanto, o servidor MySQL 5.5.50 ao qual tenho acesso não possui nenhum agrupamento com mais de um sufixo, e os únicos sufixos que vejo são: _cs, _cie _binem 198 agrupamentos no total. Usei o comando SHOW COLLATION para listá-los.

Portanto, embora pareça que o MySQL usa uma convenção de nomenclatura semelhante (pelo menos no que diz respeito a essas duas opções), não consigo encontrar um Collation correspondente ao que você está procurando. No entanto, pode ser possível retirar os acentos (e outros sinais diacríticos) e usar um _csagrupamento para obter o que deseja (semelhante a como você faria no PostgreSQL -- veja abaixo). Mas não tenho certeza dessa opção e não tenho tempo no momento para pesquisar mais.

OU , você pode criar seu próprio agrupamento para fazer exatamente o que deseja. Ao contrário dos outros RDBMSs, o MySQL parece simplificar bastante a adição de seus próprios agrupamentos, caso em que você tem controle total sobre o peso de cada caractere. Consulte Adicionando um agrupamento simples a um conjunto de caracteres de 8 bits e Adicionando um agrupamento UCA a um conjunto de caracteres Unicode para obter mais detalhes.

Para obter mais informações sobre como o MySQL lida com diferentes tipos de agrupamentos, consulte a página Tipos de implementação de agrupamento .

PostgreSQLName

Os agrupamentos no PostgreSQL parecem ser muito menos flexíveis. Você especifica apenas a cultura/localidade: en_US, de_DE, etc. Consulte a página de documentação deles para obter detalhes sobre o suporte de agrupamento . Portanto, por padrão, você obtém as substituições específicas da cultura, mas os agrupamentos são sensíveis a tudo (o que, a propósito, não é o mesmo que um agrupamento "binário").

Você pode usar ILIKE (seção 9.7.1) para obter a insensibilidade de maiúsculas e minúsculas, mas eles não têm um operador semelhante para a diferenciação de acentos. No entanto, descobri que eles têm uma função sem acento que pode ser usada para remover acentos e outros sinais diacríticos. Observe que esta função é um módulo fornecido adicional e, portanto, não está necessariamente presente em nenhum servidor PostgreSQL específico para uso. Essa documentação vinculada mais recentemente afirma:

Ao compilar a partir da distribuição de origem, esses componentes não são compilados automaticamente, a menos que você construa o destino "mundo"
...
postgresql-contrib.

Consulte a documentação para obter instruções sobre como obter essa função se você não a tiver e quiser.

Mais informações também podem ser encontradas na seguinte resposta do Stack Overflow:

O PostgreSQL suporta collations “insensíveis a acentos”?

DB2 (IBM)

Semelhante ao Microsoft SQL Server, o DB2 possui dois tipos de Collations:

• Agrupamentos "SYSTEM", que são especificados usando o seguinte formato: SYSTEM_{codepage}_[optional-territory]. Eles não são muito flexíveis e não parecem suportar a adaptação da sensibilidade a maiúsculas e minúsculas, acentos ou qualquer outra coisa. Você pode encontrar a lista de Agrupamentos suportados aqui: Códigos de território e páginas de código com suporte

• Agrupamentos baseados em Unicode Collation Algorithm (UCA). Estes suportam um pouco de alfaiataria. Consulte a página de agrupamentos baseados em Unicode Collation Algorithm para obter detalhes sobre como configurar o comportamento, a convenção de nomenclatura e a lista de localidades válidas. Observe que na Tabela 1, o exemplo na terceira linha ("Nível do caso") começa com:

  Definir o atributo Case Level como ativado e o atributo Strength como nível primário irá ignorar o acento, mas não o caso.

  Isso é exatamente o que você estava procurando. Mas, a sintaxe para isso é: CLDR181_EO_S1. E é por isso que sua pesquisa não encontrou nada relacionado ao DB2.

Oráculo

O Oracle 10g adicionou suporte para fazer comparações e classificações insensíveis a acentos. No entanto:

• eles só têm as opções para denotar operações "insensíveis": _CIe_AI
• você só pode especificar uma dessas opções por vez
• a opção que não diferencia maiúsculas de minúsculas -- _CI-- ainda é sensível a acentos
• a opção que não diferencia acentos -- _AI-- "também não diferencia maiúsculas de minúsculas." (citado de sua documentação que está vinculada abaixo)

Consulte a página de documentação Linguistic Sorting and String Searching para obter mais detalhes e exemplos.

SAP ASE (anteriormente Sybase ASE, também conhecido como Sybase)

O ASE oferece suporte a uma ou mais das seguintes combinações de sensibilidades por cada localidade/conjunto de caracteres:

• sensível a maiúsculas, sensível a acentos
• não diferencia maiúsculas de minúsculas, diferencia acentos
• não diferencia maiúsculas de minúsculas, diferencia acentos, ordem com preferência
• não diferencia maiúsculas de minúsculas, não diferencia acentos

Você pode ver a relação entre localidade, conjunto de caracteres e ordens de classificação disponíveis na página Selecionando a ordem de classificação padrão . E você pode ver a lista completa de agrupamentos na página de nomes e IDs de agrupamento .

Sua convenção de nomenclatura de agrupamento é arbitrária, pois todos têm de 4 a 8 caracteres e tentam capturar o nome da localidade ou a página de código e algum sentido da classificação. Por exemplo:

altnoacc== "Alternativa CP 850 – sem acento"
rusdict== "Ordenação do dicionário russo"
dynix== "Ordenação fonética chinesa"

Há uma observação na página Selecionando a ordem de classificação Unicode padrão afirmando:

Você pode adicionar ordens de classificação usando arquivos externos no $/collate/Unicodediretório. Os nomes e IDs de agrupamento são armazenados em arquivos syscharsets. Os nomes das ordens de classificação Unicode externas não precisam estar syscharsetsinseridos antes que você possa definir a ordem de classificação Unicode padrão.
...
Ordens de classificação Unicode externas são fornecidas pela SAP. Não tente criar ordens de classificação Unicode externas.

Não está claro se a SAP forneceria ou não uma ordem de classificação externa para permitir diferenciação de maiúsculas e minúsculas e insensibilidade de acentos. Talvez algum dia eu envie um e-mail para eles e pergunte se eles podem ser solicitados.

Para obter a combinação desejada de sensibilidades, você deve ser capaz de criar uma função escalar definida pelo usuário para remover acentos e outros sinais diacríticos.

Informix (comprado pela IBM)

O Informix parece suportar principalmente apenas a classificação padrão e o comportamento de comparação de um Collation. Portanto, Collations são apenas a localidade e o conjunto de caracteres. A diferenciação de maiúsculas e minúsculas é tratada no nível do banco de dados e, por padrão, elas diferenciam maiúsculas de minúsculas. Você pode definir um banco de dados (não uma tabela, ou uma coluna, ou uma consulta, ou mesmo um predicado) para não diferenciar maiúsculas de minúsculas especificando NLSCASE INSENSITIVE na CREATE DATABASEinstrução.

Embora o Agrupamento do banco de dados -- localidade e conjunto de caracteres -- possa ser substituído por conexão do cliente, não parece haver uma maneira de substituir a configuração de diferenciação de maiúsculas e minúsculas. E, a NLSCASEopção tem "NLS" no nome por um motivo: afeta apenas NCHARe NVARCHARdados; CHARe VARCHARsempre diferenciam maiúsculas de minúsculas.

A sensibilidade de acentos não é abordada, nem há uma função integrada para remover os acentos/marcas diacríticas.

A convenção de nomenclatura Informix Collation é:

<lang>_<country>.<code set>

Onde:

• <lang>= um código de idioma de 2 ou 3 letras
• <country>= um código de país ou região de 2 letras
• <code set>= a página de código especificada em uma das 3 formas equivalentes a seguir:
  • nome: 8859-1
  • valor decimal do número IBM CCSID: 819
  • valor hexadecimal do número IBM CCSID: 0333

Portanto, as três especificações de localidade a seguir referem-se exatamente à mesma localidade:

• fr_fr.8859-1
• fr_fr.819
• fr_fr.0333

Para mais informações, consulte:

• Guia do Usuário para IBM Informix International Language Supplement
• O arquivo de registro do IBM Informix (Windows)

Option Name Description NLS_LANG The current language, territory, and database character set, which are determined by session-wide globalization parameters. NLS_LANGUAGE The current language for the session. NLS_SORT The sequence of character values used when sorting or comparing text.

To check the current NLS settings, type:

select * from v$NLS_PARAMETERS;