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

[Marcio Ferreira]

hmm, acho que banco de dados orientado a documento foi criado
para resolver essas questões. *EU* sem devaneio faria algo assim:

{
    title: "",
    users: [],
    post: "",
    coments: [] # aninha-se os comentarios :)
    tags: []
}

E seria feliz.

usar um relacional para resolver isso ? silver bullet #detected ;)

[]s,

@_marcioferreira
Marcio Ferreira

"Perl lives as the 'toolbox for Unix' "



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

> Em 5 palavras: não vamos reinventar a roda.
> Eu diria que o fulltext *do MySQL* é horrível :P
> Obtive bons resultados com o Sphinx (http://www.sphinxsearch.com),
> inclusive para índices de dados numéricos (e não apenas texto).
>
> ABS()
>
>
>
> 2011/1/11 Lindolfo Rodrigues Oliveira Neto <lorn.br at gmail.com>
>
> 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: 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
>>
>>
>
> =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/437ca72b/attachment-0001.html>