Pensei sobre isso e tenho tentado encontrar soluções sobre como pesquisar um banco de dados nebuloso, se, por exemplo, um usuário digitar um erro de ortografia. Algum problema flagrante com a lógica por trás disso? Será que vai funcionar e já foi feito antes?
Nossa tabela queremos pesquisar:
**tblArticles**
Body - Soundex_Body - CharacterCoded_Body
Portanto, armazenamos o corpo do texto bruto para exibição física. As outras 2 colunas são usadas para pesquisas pré-computadas da seguinte maneira:
Soundex
O corpo é dividido em suas palavras e traduzido para sua versão soundex. IE, o corpo resultante pode ser algo como:
H252 B54 C23 E33... etc
Assim, alguém pode entrar em 'dinosore', e o corpo do artigo lê 'dinosaur', que ambos avaliam para B26. Em seguida, executamos um LIKE no valor soundex do termo de pesquisa.
Caractere codificado
Dado um mapeamento de caracteres que mapeia caracteres para números primos, o IE:
h = 2
e = 3
l = 5
o = 7
p = 11
c = 13
help = 2*3*5*11 = 330
hello = 2*3*5*5*7 = 1050
hell = 2*3*5*5 = 150
hlep = 2*5*3*11 = 330
cello = 13*3*5*5*7 = 6825
Se um usuário pretender digitar 'olá', mas alternar dois ou mais caracteres, por exemplo, 'hlelo', será avaliado com o mesmo número. Divida o corpo bruto em palavras, codifique primeiro todas as palavras e armazene no banco de dados, oferecendo um campo parecido com:
330 6825 330 1050... etc
Podemos então pesquisar neste valor para corresponder a erros de digitação.
Benefícios
- Erros de digitação protegidos contra
- Ortografia incorreta fonética protegida contra
- Mais amigável para quem não fala inglês nativo
- Funcionará em qualquer idioma (onde o soundex funciona)
Comentários e pensamentos? Uma espécie de pesquisa em várias camadas. É claro que você pode ponderar os valores de retorno para torná-lo ainda melhor (ou seja, uma correspondência literal do corpo do texto vale mais), mas essa é uma boa solução para erros de ortografia e falantes não nativos de inglês fazendo pesquisas?
Respostas:
Existem vários outros algoritmos de pesquisa. Smith-Waterman é um dos melhores para o texto humano, enquanto o BLAST é (até agora) o melhor para pesquisar sequências de DNA. Quando você recebe um texto com vários erros ortográficos, como em
hlepvez dehelp, procura a distância mínima de edição .Para que uma biblioteca implemente várias dessas funções no CLR no SQL Server 2005 (e posterior), consulte o projeto de forja de origem SimMetrics . Postagem no blog sobre o SimMetrics .
http://staffwww.dcs.shef.ac.uk/people/S.Chapman/simmetrics.html
O Soundex foi desenvolvido porque as principais diferenças entre as variações regionais de fala foram quase exclusivamente nas vogais - e é por isso que as vogais são descartadas. Não é bom em lidar com letras transpostas.
fonte
O Apache Solr suporta sinônimos e correções ortográficas - embora ainda seja um pouco áspero nas bordas.
Pesquisas difusas podem ser implementadas usando Ngrams,
Porter Stemmer: http://tartarus.org/~martin/PorterStemmer/
e um banco de dados de idiomas como http://wordnet.princeton.edu/
... mas projetos como Xapian e Solr tratam muito disso para você.
Se você deseja criar seu próprio mecanismo de análise / pesquisa de termos de pesquisa por palavras, sugiro colocar os tokens ou termos que você gerar em um banco de dados existente, projetado para executar a pesquisa por idioma.
fonte
Eu fiz algo parecido há algum tempo para endereços que verificariam quantas alterações seriam necessárias para transformar uma sequência em outra e retornasse um valor numérico entre 0 e 1 para determinar a proximidade entre as duas.
Funcionou muito bem, pois retornaria um valor alto para itens como N / Norte, St / Street, EastMain / MainEast, etc. A idéia veio desse link do CodeProject
fonte
Se você estiver combinando nomes, pessoas ou lugares, uma lista de sinônimos poderá funcionar muito melhor.
O Soundex não corresponderá a "Dick == Richard" "Kit == Christopher" ou "Ms. == Mrs."
fonte