Staninslaw, Fulltext é horrivel ! o melhor jeito de se fazer busca é usando uma estrutura de dados baseada em 'Indice Invertido'
http://en.wikipedia.org/wiki/Inverted_index No CPAN tem o Kinosearch http://search.cpan.org/search?query=kinosearch&mode=all que usa isso, mas eu recomendo fortemente o Solr O marcioferreira fez alguns benchmark a pouco tempo sobre isso, caso esteja vivo e queira contribuir para a thread :) On Jan 11, 2011, at 6:32 PM, Stanislaw Pusep wrote: > > Stanislaw> Agora, falando sério: eu quero que o meu blog tenha um > Stanislaw> sisteminha básico de busca de conteúdo. > > Que bom que você falou disso, nesse caso você deveria ficar longe de > bancos de dados relacionais porque a forma padrão de se implementar uma > busca por texto é indexar documentos desnormalizados. Assim um /john/ > vai encontrar ocorrências no documento inteiro (seja no título, autor, > corpo, etc.). Num banco de dados relacional você gasta processamento > a mais porque precisa fazer where title like '%john%' or author like > '%john%' e esse tipo de busca nunca vai sempre ser um table scan, que é, > como diria um amigo meu, "lento pacas", além de ser mais complicado de > implementar. > > FULLTEXT? > > > Stanislaw> Também acho legal que os posts novos contenham > Stanislaw> referências para posts antigos; e, como a minha memória é > Stanislaw> ruim, prefiro que o CMS faça isso automaticamente. > > O que impede o CMS de te apontar pruma url que coincide com o documento > que você quer referenciar? > > Supondo: estou escrevendo resenha sobre iPad. O sistema deve > "automagicamente" (categorias, tags, indexação do conteúdo, whatever) > associar esse artigo com resenhas de iPhone, iPod, iMac. Em blog pequeno até > pode ser viável scanear tudo sempre que artigo novo é criado... > > Stanislaw> Um esqueminha de comentários c/threads é bacaninha > Stanislaw> também; > > Escreve pra mim o SQL que recupera todos os nós dentro de uma thread com > profundidade arbitrária. Difícil né? Agora põe esse SQL pra rodar num > benchmark contra um filesystem: "lento pacas". > > use Data::NestedSet; > > > Stanislaw> sem falar de um filtro anti-spam bayesiano... > > Por definição, um filtro remove elementos do stream *antes* deles > chegarem no storage, então esse requisito é completamente ortogonal à > escolha do storage. E mesmo assim, a natureza sequencial dos filtros > também seriam lentos e complicados de implementar num banco de dados > relacional pelos mesmos motivos da busca. > > Filtro que se preza é treinável. Vou manter (black|white)list como? tie > %hash, 'DB_File'? > > Stanislaw> Faltou algum argumento para empregar RDBMS? > > Tire suas próprias conclusões. > > Provando por absurdo e desprezando o atrito: OK, um blog pode ser um > emaranhado de arquivos organizados em diretórios. Porém vai ter que ter um > (ou mais) índice. Talvez em CSV. E por que não dbmopen? Ou, quem sabe, > Berkeley DB. Mas melhor mesmo seria SQLite. Opa!!! > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
