> >>>>> "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. >
É exatamente esse o "opa!!!" da questão. Se vai ousar SQLite, já mete um MySQL ou PostgreSQL de vez. Datacenters decentes usam servidores dedicados para banco de dados (alguns usam até discos dedicados, evitando o overhead do filesystem). Parece exagero, mas antes sobrar recurso no começo do projeto do que faltar no meio :) Uma objeção a manter os índices desvinculados do conteúdo: sincronização sempre é boa na teoria; jamais na prática.
=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
