[SP-pm] [OT] Possível Oportunidade

[Hernan Lopes]

Alguem pode fazer um resumo de até 5 linhas do que aprendemos nestes 50
emails ?

2011/1/11 Stanislaw Pusep <creaktive at gmail.com>

>
>    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: SaoPaulo-pm at pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110111/26d373b0/attachment-0001.html>