Pode ser 5 palavras? Bancos são feitos em filesystem! 2011/1/11 Hernan Lopes <[email protected]>
> 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 > > -- Renato Santos http://www.renatocron.com/blog/
=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
