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