Início / dba / Perguntas / 190969
Accepted
lumo
Asked: 2017-11-16 02:02:21 +0800 CST

Ignorar acentos na cláusula 'where'

  • 772

Em nosso banco de dados, temos várias entradas com acentos graves, acentos circunflexos ou carons (aka hačeks). Esses acentos são coletivamente também conhecidos como sinais diacríticos .

Agora, nossos usuários desejam encontrar entradas que incluam esses sinais diacríticos quando pesquisam entradas sem. Vou mostrar isso com um exemplo simples:

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

Millière

...então este nome está correto no país em que a pessoa vive.

Em nosso país não temos caracteres com sinais diacríticos, portanto nosso usuário procura por Milliere. Nenhum resultado aparece, como èobviamente não corresponde e.

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

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

sql-server sql-server-2008

1 respostas

  1. Best Answer

    Esse problema pode ser resolvido usando collations sem distinção de acentos .

    Seu banco de dados provavelmente está usando um agrupamento AS (Accent Sensitive), portanto, 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.

    Neste dbfiddle , criei um exemplo usando os agrupamentos LATIN1, mas você pode usar a mesma abordagem com o agrupamento que está usando apenas alterando AS para AI para o agrupamento que sua coluna está usando no momento.

    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_AIand not Latin1_General_CI_ASou Latin1_General_100_CI_ASou qualquer uma das variações desses dois, pois o comportamento dos agrupamentos não SQL_ será diferente em mais maneiras do que apenas a insensibilidade ao acento, e isso pode não ser esperado pelos usuários.

    Você pode verificar o agrupamento atual em 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 o SQL Server Collations para obter mais informações.

    Então, novamente, você provavelmente deseja que a classificação use esse agrupamento (como peufeu observou 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 esperavam que estivessem, 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 afetar 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 insensível ao acento e, em seguida, indexe o cálculo coluna. Isso evita a verificação causada pela alteração do agrupamento na consulta. Em seguida, a consulta precisa filtrar na 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).

    • 38

relate perguntas