>>>>> "Stanislaw" == Stanislaw Pusep <[email protected]> writes:
Stanislaw> FULLTEXT?
Se seus registros vão todos ter um único campo fulltext, qual a
utilidade de se usar um banco de dados relacional?
Stanislaw> Supondo: estou escrevendo resenha sobre iPad. O sistema
Stanislaw> deve "automagicamente" (categorias, tags, indexação do
Stanislaw> conteúdo, whatever) associar esse artigo com resenhas de
Stanislaw> iPhone, iPod, iMac. Em blog pequeno até pode ser viável
Stanislaw> scanear tudo sempre que artigo novo é criado...
E qual seria a forma mais viável de scanear?
Stanislaw> use Data::NestedSet;
E junto com as consultas nested set (que são uma gambiarra pra driblar
as limitações semânticas de SQL), a implantação do schema e a
complexidade O(n^2).
Stanislaw> Filtro que se preza é treinável. Vou manter
Stanislaw> (black|white)list como? tie %hash, 'DB_File'?
Ok, pro storage do anti-spam não faço idéia do que usar, mas estamos
falando do storage do blog, não das features acessórias.
Stanislaw> Provando por absurdo e desprezando o atrito: OK, um blog
Stanislaw> pode ser um emaranhado de arquivos organizados em
Stanislaw> diretórios. Porém vai ter que ter um (ou mais)
Stanislaw> índice. Talvez em CSV. E por que não dbmopen? Ou, quem
Stanislaw> sabe, Berkeley DB.
Ok, índices são necessários se o blog tiver um mecanismo busca
próprio. Particularmente, eu prefiro usar a indexação do google prum
blog pequeno, ou algo como kinosearch, lucene ou sphinx, que são bem
mais eficientes que dbm/berkeley.
Stanislaw> Mas melhor mesmo seria SQLite. Opa!!!
Tem certeza? Operações de escrita no SQLite fazem lock no arquivo
inteiro. Significa que os usuários de um blog muito solicitado vão
sentir um "soluço" no sistema sempre que você modificar alguma coisa.
--
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
