Alguem pode fazer um resumo de até 5 linhas do que aprendemos nestes 50 emails ?
2011/1/11 Stanislaw Pusep <[email protected]> > > 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
