• Revista PROGRAMAR: Já está disponível a edição #53 da revista programar. Faz já o download aqui!

kahoz

expressões regulares / fulltext [act]

22 mensagens neste tópico

boas noites,

nos sistemas de pesquisa que desenvolvo tenho utilizado nas querys coisas como "LIKE '% texto %'" ou "LIKE '%texto%'", que se tem revelado inificazes..

entertanto soube recentemente que é possível usar regex em sql, mas como não domino o assunto (regex), como é que faço para procurar por um caracter ?

.. obg desde já (;

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Epa... aí está uma questão que  me desperta a curiosidade.

Já andei pelas mailing lists e pelos fóruns oficiais do mysql e nunca me deram ajuda nenhuma neste ponto.

Eu uso esse tipo de pesquisa... na verdade funciona sem problemas... mas olhando assim a frio não tem nada bom aspecto.

O máximo que me disseram foi:

"dependendo da situação isso até pode na verdade servir"

epa... isto para mim n é ajudar... assim como a minha resposta n é grande ajuda... pa... boa sorte... se descobrires qual a forma de fazer isso em condições afixa aí que eu tb estou curioso.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

O problema é que o LIKE apanha tudo o que tiver no meio do texto.

Se procurar por '%maos%', o sgbd devolve resultados onde esteja contido 'irmaos' (ok sei que falta o til mas acho que percebeste..) era este tipo de situações que queria evitar.

E depois outra, ordena os resultados por relevância.. :P

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

em vez de colocares '%palavra%'  podes só colocar '%Palavra'  ou  'Palavra%' dependo que queres procurar...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

full text search com indexes invertidos e muito mais rapido do que LIKE

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Dabubble, acho que se fulltext fosse mais rapido que o LIKE os pesquisadores feitos em php utilizariam fulltext e não LIKE

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

em vez de colocares '%palavra%'  podes só colocar '%Palavra'  ou  'Palavra%' dependo que queres procurar...

like '%palavra' or like 'palavra%'

e

like '%palavra%'

é a mesma coisa..  :hmm:

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não... 

'%ABC'    <- Isto procura por palavras que terminem com ABC

'ABC%'     <- Isto procura por palavras que começem com ABC

'%ABC%'   <- Isto procura por palavras que têm ABC

Tipo antes de dizeres que são a mesma coisa podias tentar pesquisar...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Esse é um problema com que as BDs se deparam muitas vezes. Uma solução genérica passa pelo uso da % em cláusulas like, onde o utilizador pode definir onde colocar o símbolo % (ou usar o * que é normalmente um simbolo mais conhecido e depois trocar o * por %). Outras vezes é dada a hipótese do utilizador escolher se a pesquisa deve ser um AND ou um OR para todas as palavras usadas, ou seja:

- AND: select * from tabela where campo like '%caracteres1%' AND campo like '%caracteres2%' AND ... AND campo like '%caracteresN%'

- OR : select * from tabela where campo like '%caracteres1%' OR campo like '%caracteres2%' OR ... OR campo like '%caracteresN%'

Por vezes o sistema não pede nada ao utilizador e assum uma das estratégias acima. Isto pode evoluir para algo mais complexo, do tipo, o utilizador dizer "chars1 AND (chars2 OR chars3)", mas não creio que tal seja necessário aqui.

Outra estratégia, mais pesada e menos usada, é usar % entre cada caracter: select * from tabela where campo like '%caracter1%caracter2%...%caracterN%'

Se o FullTextSearch te resolve o problema e não causa impacto na performance, usa-o, caso contrário podes usa uma das estratégias acima.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

M6 para pesquisas utiliza-se o LIKE porque é melhor, exemplo se tu queres criar um pesquisador que procura por conteúdos no teu site tu utilizas LIKE e não fulltext....

Ele quer fazer procuras e para procuras o melhor é utilizar LIKE.

E para veres que se utiliza mais o LIKE abre os ficheiros do php-nuke, joomla, mambo etc...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

M6 para pesquisas utiliza-se o LIKE porque é melhor, exemplo se tu queres criar um pesquisador que procura por conteúdos no teu site tu utilizas LIKE e não fulltext....

Ele quer fazer procuras e para procuras o melhor é utilizar LIKE.

E para veres que se utiliza mais o LIKE abre os ficheiros do php-nuke, joomla, mambo etc...

Isso que afirmas é demasiado radical e nem sequer é suportado por factos.

Uso o LIKE há muito anos e sei bem que o mesmo é o mais usado, em especial por ser uma cláusula implementada em "todos" os SGBDs.

No entanto, o facto de se usar mais o LIKE não quer dizer que o Full Text não seja a melhor solução para um determinado caso. O Full Text Index é muito superior ao Like, permite efectuar pesquisas mais complexas que com o Like podem ser extremamente complexas e pesadas.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não... 

Tipo antes de dizeres que são a mesma coisa podias tentar pesquisar...

entao

SELECT * FROM tabela WHERE campo LIKE '%palavra' OR campo LIKE 'palavra%'

e

SELECT * FROM tabela WHERE campo LIKE '%palavra%'

.. nao dá os mesmos resultados ?

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Não... 

Tipo antes de dizeres que são a mesma coisa podias tentar pesquisar...

entao

SELECT * FROM tabela WHERE campo LIKE '%palavra' OR campo LIKE 'palavra%'

e

SELECT * FROM tabela WHERE campo LIKE '%palavra%'

.. nao dá os mesmos resultados ?

Não obrigatoriamente, no primeiro caso estrás à procura de texto que começa ou termina por 'palavra', no segundo estás à procura de texto onde existe 'palavra'.

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Yah... do tipo....

+-------------+

|    Barco    |

+-------------+

|      Mar      |

+-------------+

|      Arma    |

+-------------+

Com o LIKE '%ar%' vai mostrar os registos todos da tabela acima...

Com o LIKE 'ar%' vai mostrar o registo arma...

Com o LIKE '%ar' vai mostrar o registo mar...

Logo, ao fazer LIKE 'ar%' OR LIKE '%ar' (a sintaxe ta mal, mas é para usarem a logica xD) mas vai mostrar os registos todos da tabela acima menos Barco, pois  este nem começa com 'ar', nem acaba com 'ar'...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Dabubble, acho que se fulltext fosse mais rapido que o LIKE os pesquisadores feitos em php utilizariam fulltext e não LIKE

Tipo usa-se LIKE para querys simples e porque esta a mao e porque todos os SGBDs utilizam. Se percebes de base de dados o que acontece e o seguinte se fizeres um like a uma determinada coluna podem acontecer duas coisas:

Se a coluna estiver indexada a pesquisa e relativamente rapida mas e feita num index normal ou seja tens de percorrer o index quase todo mas ate nem e muito mau por que um index normal ate e eficiente

Se a coluna nao estiver indexada (muitas sgbds nao permitem indexar colunas com um comprimento mais do que X) tens de fazer um FULL TABLE SCAN para teres os resultados de um LIKE

As SGBDS que possibilitam o uso de Full text search fazem-no com indexes invertidos e isto significa que o que o index guarda e um conjunto de termos (as palavras) que apontam para os documentos (linhas da tabela e, por vezes, posicao nessas linhas) que as contêm.

Esta estrutura faz com que as pesquisas sejam muito mais rapidas, para tabelas grandes normalmente duas ordens de magnitude ou mas a diferenca aumenta com o aumento da tabela.

Desvantagem e que se fica agarrado a SGBD porque normalmente cada uma implementa com a sua propria sintaxe e nem todas tem a funcionalidade (dai as ferramentas que mencionaste nao usarem). Para dar a volta a tal problema pode-se utilizar uma ferramenta como o Lucene para indexares tu proprio o que percisas de pesquisar.

EDIT:

Para o problema que tu indicaste inicialmente (de procurares por mao e aparecer irmao) o full text search e a solucao isto porque ele so te da um match se a palavra for a mesma e nao parecida (alguns processao acentos e raizes etimologicas para  descobrir palavras identicas)

Outra coisa ainda na questao do LIKE nao e o que e melhor ou pior e o que deve ser utilizado em cada situacao para procurar palavras numa coluna de uma tabela um full text search e melhor, agora se estas por exemplo a procura de todas as palavras acabam em kk koisa ou que contem kk koisa no meio ai full text search nao funciona e tem de usar LIKE. Isto tem a haver com a maneiro como os indices sao contruidos...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

E já que falamos em FULLTEXT...

Eu tenho ideia de que as pesquisas FULLTEXT são boas para campos grandes do tipo LONGTEXT onde não sabemos a Key Length para o indíce... (nota: sou 1 kito n00b ainda, se tiver a dizer asneiras CORRIJAM-ME)

Já as pesquisas com LIKE têm como base campos mais pekenos do tipo VARCHAR que vão até 255 caracteres.. salvo erro...

A minha dúvida (caso aquilo esteja correcto) é a seguinte...

Porque é que as pesquisas FULLTEXT são MUITO mais LENTAS quando envolvem campos de várias tabelas??? É por fazerem pesquisas em variados INDEXES?...

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

E já que falamos em FULLTEXT...

Eu tenho ideia de que as pesquisas FULLTEXT são boas para campos grandes do tipo LONGTEXT onde não sabemos a Key Length para o indíce... (nota: sou 1 kito n00b ainda, se tiver a dizer asneiras CORRIJAM-ME)

Já as pesquisas com LIKE têm como base campos mais pekenos do tipo VARCHAR que vão até 255 caracteres.. salvo erro...

A minha dúvida (caso aquilo esteja correcto) é a seguinte...

Porque é que as pesquisas FULLTEXT são MUITO mais LENTAS quando envolvem campos de várias tabelas??? É por fazerem pesquisas em variados INDEXES?...

1º Full text e sempre melhor para procurar por palavras inteiras do que LIKE que era a situacao inicial deste topico (talvez nao para pouquissimos registos mas torna-se aparente cedo (< 500))

Full Text usa um indice complexo cuja escrita nao e triviar, assim algumas outras operacoes podem ser atrasadas por usar full text (mas normalmente e negligenciavel)

2º LIKE faz o match na procura por uma sequencia de caracteres (FT faz a toda a palavra) servindo para pesquisas diferentes

Agora finalmente respondendo a tua pergunta:

Sim e nao :D depende do tipo de full text engine que uses, os SGBDS podem criar varios indices ou so um (dependendo de qual e) se bem que o caso normal e terem varias (pelo menos um por tabela e por vezes um por coluna). A pesquisa e sem duvida mais lenta, numa relacao directamente propocional ao nomero de indices pesuisados.

A solucao e implementares tu o tem proprio indice :D e (relativamente) facil de fazer e tem a vantagem que podes incluir conteudo HTML para alem do conteudo da tua base de dados

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Esta discussão está interessante e está a entrar num nível de detalhe mais profundo. Vou explicar um pouco mais o que acontece nos campos de texto. Aviso desde já que o texto é um tanto ou quanto longo.

Os SGBDs guardam os registos nas tabelas (até aqui nada de novo :D) e essas tabelas correspondem, modo geral, a um conjunto de ficheiros no sistema (pode não ser bem assim, caso a bd use técnicas como "file system in a file", mas isso agora não é relevante).

Cada tabela tem associado um conjunto de informação: a sua estrutura, tipos de dados, o tamanho e precisão dos campos, etc.  A isto chama-se metadados, ou seja, dados sobre os dados.

Cada tabela costuma ter também, pelo menos, um índice ao nível da chave da tabela (isto pode não ser bem assim dado que cada SGBD tem as suas particularidades, mas assumir isto não é errado). Esses índices costumam também ser guardados num ficheiro à parte e contém uma estrutura, tipo B-Trees e outras, que permite pesquisar uma informação de forma mais rápida.

Depois há outras coisas mais intrinsecas ao SGBD não totalmente especifico da BD, como é o caso dos Logs, mas isso fica para outras "núpcias" (embora se houver alguém interessado, possa falar um pouco sobre isto).

Quando se define a estrutura de uma tabela, fica associado um tamanho por registo, sendo a tabela construída sabendo que esse é o tamanho máximo de cada registo. Quando um registo é inserido na tabela, o espaço que este ocupa nunca é sempre o mesmo. Excepção feita aos tipos de dados variáveis, como os varchar, mas é sempre garantido que não excedem o tamanho máximo.

Quanto aos tipos "especiais" como "text" ou certos tipos de dados binários, dado que não é possível estimar o tamanho máximo dos dados, aquando da insersão de um registo na tabela, uma parte é guardada na tabela e o restante fica num ficheiro à parte.

Assim sendo, os dados de uma tabela podem ficar dispersos em vários ficheiros, impactando directamente a performance da recuperação de dados da BD.

Desta forma, os operadores como LIKE podem ter performances diferentes dependendo do tipo de dados e da forma como os mesmo estão guardados.

Uma das técnicas mais comuns para melhorar a performance na recuperação de dados passa pela criação de indices. Um índice deve ser criado com cuidado. Quando se cria um índice há que ter em atenção que o mesmo pode ter o efeito inverso ao esperado, ou seja, pode tornar o acesso à tabela mais lento em vez de reduzir o tempo de acesso.

Há que ter em atenção que cada índice criado para ajudar a pesquisa, implica um tempo de criação e alteração de registos superior, uma vez que cada operação dessas necessita de fazer uma actualização a todos os índices da tabela.

E pronto, acho que fico por aqui não vá alguém adormecer com este texto... :D

0

Partilhar esta mensagem


Link para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!


Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.


Entrar Agora