Ignorar acentos em 'onde'


17

Em nosso banco de dados, temos várias entradas com caron / hatschek. Agora, nossos usuários desejam encontrar entradas, incluindo caron / hatschek, quando pesquisam entradas sem. Vou mostrar isso por um exemplo simples:

Em nosso banco de dados, temos a entrada (contato com nome)

Millière

portanto, esse nome está correto no país em que a pessoa mora.

Em nosso país, não temos caracteres com caron / hatschek, portanto, nosso usuário procura Milliere. Nenhum resultado aparece, pois èobviamente não corresponde e.

Eu não tenho nenhuma idéia de como isso poderia ser realizado como é, è, êe muitos mais estão disponíveis (e este é apenas um exemplo para letra e...).

(A outra maneira seria muito mais fácil, pois eu poderia simplesmente substituir todas as letras por caron / hatschek pela básica. Obviamente, nossos usuários desejam a versão correta do nome no banco de dados, não a aleijada.)


Observe que a letra "è" não possui um caron / hacek, possui um sotaque grave; um caron / hacek seria "ě". Você quer dizer "personagens com sotaque" ou algo assim? Ou você quer dizer especificamente o sotaque caron / hacek?
Psmears

refiro-me a qualquer caractere com "sinais" (desculpe, eu não sei o nome real dele).
lumo

Respostas:


31

Esse problema pode ser resolvido usando agrupamentos insensíveis ao acento .

Seu banco de dados provavelmente está usando um agrupamento AS (Accent Sensitive). Por padrão, ele procurará a correspondência exata, incluindo acentos.

Você pode instruir a cláusula WHERE a usar outro agrupamento que não o padrão do banco de dados, especificando um agrupamento com a comparação.

Em deste dbfiddle eu criei um exemplo usando os agrupamentos LATIN1 mas você pode usar a mesma abordagem com o agrupamento que você está usando apenas mudando AS em AI para o agrupamento a sua coluna está usando atualmente.

Use o agrupamento Accent Insensitive que corresponde ao agrupamento que a coluna está usando. Por exemplo, se a coluna estiver usando SQL_Latin1_General_CP1_CI_AS, use SQL_Latin1_General_CP1_CI_AIe não Latin1_General_CI_ASou Latin1_General_100_CI_ASou qualquer uma das variações dessas duas, uma vez que o comportamento dos agrupamentos não-SQL_ diferirá em mais maneiras do que apenas insensibilidade ao sotaque, e isso pode não ser esperado pelos usuários.

Você pode verificar o agrupamento atual sys.columns.

CREATE TABLE testaccent (name nvarchar(50));
GO
INSERT INTO testaccent (name) VALUES ('Millière') , ('Milliere');
GO
-- returns Miliere
SELECT * FROM testaccent WHERE name = 'Milliere';

-- returns both
SELECT * FROM testaccent WHERE name='Milliere' COLLATE Latin1_General_CI_AI

--only returns Miliere
SELECT * FROM testaccent WHERE name='Milliere' COLLATE Latin1_General_CI_AS

Leia Usando agrupamentos do SQL Server para obter mais informações.

Então, novamente, você provavelmente desejaria classificar para usar esse agrupamento (como observou peufeu nos comentários) para garantir que "é" seja classificado com "e". Caso contrário, alguém que pagina os resultados em ordem alfabética ficaria surpreso em não encontrar o "é" onde eles esperam que eles estejam, mas se você quiser apenas tocar nessa consulta, poderá adicionar a COLLATEcláusula ORDER BYtambém.

Conforme observado por Solomon Rutzky nos comentários, se isso afeta apenas 1 ou algumas colunas, outra opção é criar uma coluna computada não persistente que simplesmente repita a coluna "nome" e forneça o agrupamento sem distinção de acento e, em seguida, indexe o computador calculado coluna. Isso evita a verificação causada pela alteração do agrupamento na consulta. Em seguida, a consulta precisa filtrar a nova coluna.

Algo como:

ALTER TABLE 
dbo.[table_name] ADD [SearchName] datatype_of_name_column 
AS ([Name] COLLATE LATIN1_GENERAL_100_CI_AI)); 

CREATE INDEX [IX_table_name_SearchName] 
ON dbo.[table_name] ([SearchName] ASC);

Ou você também pode criar uma visualização em vez de adicionar uma coluna computada (como jyao prefere).


1
Tom: Eu observaria (e destacaria) que eles deveriam usar a versão Accent-Insensitive do Collation que a coluna está usando (o agrupamento padrão do banco de dados, mencionado no parágrafo 3, não é relevante para esta questão). Se a coluna estiver em uso SQL_Latin1_General_CP1_CI_AS, use SQL_Latin1_General_CP1_CI_AIe não Latin1_General_CI_ASou Latin1_General_100_CI_ASou qualquer uma das variações dessas duas, uma vez que o comportamento dos não SQL_agrupamentos diferirá em mais aspectos do que apenas insensibilidade ao sotaque, e isso pode não ser esperado pelos usuários. O agrupamento é encontrado em sys.columns.
Solomon Rutzky

@SolomonRutzky boa sugestão
Tom V - Team Monica
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.