>>>>> "Stanislaw" == Stanislaw Pusep <[email protected]> writes:
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.
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?
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".
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.
Stanislaw> Faltou algum argumento para empregar RDBMS?
Tire suas próprias conclusões.
--
Eden Cardim
Software Engineer
+55 73 9986-3963
edencardim.com
=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
