<span dir="ltr"></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Stanislaw> Agora, falando sério: eu quero que o meu blog tenha um<br>
Stanislaw> sisteminha básico de busca de conteúdo.<br>
<br>
Que bom que você falou disso, nesse caso você deveria ficar longe de<br>
bancos de dados relacionais porque a forma padrão de se implementar uma<br>
busca por texto é indexar documentos desnormalizados. Assim um /john/<br>
vai encontrar ocorrências no documento inteiro (seja no título, autor,<br>
corpo, etc.). Num banco de dados relacional você gasta processamento<br>
a mais porque precisa fazer where title like '%john%' or author like<br>
'%john%' e esse tipo de busca nunca vai sempre ser um table scan, que é,<br>
como diria um amigo meu, "lento pacas", além de ser mais complicado de<br>
implementar.<br></blockquote><div><br>FULLTEXT?<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Stanislaw> Também acho legal que os posts novos contenham<br>
Stanislaw> referências para posts antigos; e, como a minha memória é<br>
Stanislaw> ruim, prefiro que o CMS faça isso automaticamente.<br>
<br>
O que impede o CMS de te apontar pruma url que coincide com o documento<br>
que você quer referenciar?<br></blockquote><div><br>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...<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Stanislaw> Um esqueminha de comentários c/threads é bacaninha<br>
Stanislaw> também;<br>
<br>
Escreve pra mim o SQL que recupera todos os nós dentro de uma thread com<br>
profundidade arbitrária. Difícil né? Agora põe esse SQL pra rodar num<br>
benchmark contra um filesystem: "lento pacas".<br></blockquote><br>use Data::NestedSet;<br> <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Stanislaw> sem falar de um filtro anti-spam bayesiano...<br>
<br>
Por definição, um filtro remove elementos do stream *antes* deles<br>
chegarem no storage, então esse requisito é completamente ortogonal à<br>
escolha do storage. E mesmo assim, a natureza sequencial dos filtros<br>
também seriam lentos e complicados de implementar num banco de dados<br>
relacional pelos mesmos motivos da busca.<br></blockquote><div><br>Filtro que se preza é treinável. Vou manter (black|white)list como? tie %hash, 'DB_File'?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Stanislaw> Faltou algum argumento para empregar RDBMS?<br>
<br>
Tire suas próprias conclusões.<br></blockquote><div><br>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!!!<br>
</div></div>