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

[Renato Santos]

Pode ser 5 palavras?
Bancos são feitos em filesystem!

2011/1/11 Hernan Lopes <hernanlopes at gmail.com>

> 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
>>
>>
>
> =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
>
>


-- 
Renato Santos
http://www.renatocron.com/blog/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110111/c6c8b5e2/attachment.html>