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

[Eden Cardim]

>>>>> "Stanislaw" == Stanislaw Pusep <creaktive em gmail.com> 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