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

[Eden Cardim]

>>>>> "Stanislaw" == Stanislaw Pusep <creaktive em gmail.com> writes:

    Stanislaw> É exatamente esse o "opa!!!" da questão. Se vai ousar
    Stanislaw> SQLite, já mete um MySQL ou PostgreSQL de
    Stanislaw> vez.

Bom, devaneando um pouco do tópico. A arquitetura do mysql/pg é de
cliente/servidor, *bem* diferente do SQLite e bem mais complicado de
implantar/distribuir. No sqlite as operações são executadas de forma
descentralizada (por isso a necessidade de lock a nível de arquivo). Em
muitos casos o ROI dessa complexidade inviabiliza o uso de mysql/pg
invés de sqlite, principalmente em aplicações que são tipicamente
mono-usuário (browsers, editores de texto, clientes de email, software
para dispositivos móveis em geral, etc.), e é pra esses casos que o
sqlite existe.

Voltando ao tópico, a discussão sqlite vs mysql/pg é pouco relevante na
discussão sobre blog porque bancos de dados relacionais são pouco
adequados para o core de um blog, como já demonstrei em posts
anteriores.

    Stanislaw> Datacenters decentes usam servidores dedicados para banco
    Stanislaw> de dados (alguns usam até discos dedicados, evitando o
    Stanislaw> overhead do filesystem).

Como assim "evitando o overhead do filesystem"? Pra não passar pelo
filesystem, o software do banco de dados precisaria conhecer detalhes de
implementação de gestão do hardware do sistema operacional em todas as
variações de plataforma onde ele vai ser implantado, o que é inviável em
termos de gestão de projeto, por isso nenhum banco de dados faz isso
(pelo menos o mysql e o postgresql não fazem). Posso estar enganado mas
a única forma que vejo de viabilizar isso seria se o datacenter
fornecesse patches pro banco de dados operar dessa forma. A Percona, por
exemplo, é especializada em fazer esse tipo de coisa com mysql, mas eles
cobram muito mais do que seria viável prum datacenter.

-- 
Eden Cardim
Software Engineer
+55 73 9986-3963
edencardim.com