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

[Stanislaw Pusep]

> >>>>> "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.
>

É 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.
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110112/6c0cb7f9/attachment-0003.html>