[SP-pm] [OT] Possível Oportunidade
Eden Cardim
edencardim at gmail.com
Tue Jan 11 11:47:26 PST 2011
>>>>> "Stanislaw" == Stanislaw Pusep <creaktive em gmail.com> 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
More information about the SaoPaulo-pm
mailing list