<span dir="ltr"></span><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> Stanislaw> É exatamente esse o "opa!!!" da questão. Se vai ousar<br>
Stanislaw> SQLite, já mete um MySQL ou PostgreSQL de<br>
Stanislaw> vez.<br>
<br>
Bom, devaneando um pouco do tópico. A arquitetura do mysql/pg é de<br>
cliente/servidor, *bem* diferente do SQLite e bem mais complicado de<br>
implantar/distribuir. No sqlite as operações são executadas de forma<br>
descentralizada (por isso a necessidade de lock a nível de arquivo). Em<br>
muitos casos o ROI dessa complexidade inviabiliza o uso de mysql/pg<br>
invés de sqlite, principalmente em aplicações que são tipicamente<br>
mono-usuário (browsers, editores de texto, clientes de email, software<br>
para dispositivos móveis em geral, etc.), e é pra esses casos que o<br>
sqlite existe.<br></blockquote><div><br>MySQL só não precisa de "lock explícito" por que ele é o único quem acessa os seus próprios arquivos (duh) então supõe-se que use um mecanismo interno coerente para sequenciar os acessos ao storage.<br>
E nada impede que o SQLite seja usado como *backend* para um modelo cliente/servidor: <a href="http://users.libero.it/irwin/" target="_blank">http://users.libero.it/irwin/</a><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Voltando ao tópico, a discussão sqlite vs mysql/pg é pouco relevante na<br>
discussão sobre blog porque bancos de dados relacionais são pouco<br>
adequados para o core de um blog, como já demonstrei em posts<br>
anteriores.<br></blockquote><div><br>Presumo que a sua definição de um "blog" seja diferente da minha :)<br>Eu me sentiria desmotivado se tivesse que implementar esse site do zero: <a href="http://iwatcher.net/">http://iwatcher.net/</a> (observe especialmente isso: <a href="http://iwatcher.net/feeds/">http://iwatcher.net/feeds/</a>)<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Stanislaw> Datacenters decentes usam servidores dedicados para banco<br>
Stanislaw> de dados (alguns usam até discos dedicados, evitando o<br>
Stanislaw> overhead do filesystem).<br>
<br>
Como assim "evitando o overhead do filesystem"? Pra não passar pelo<br>
filesystem, o software do banco de dados precisaria conhecer detalhes de<br>
implementação de gestão do hardware do sistema operacional em todas as<br>
variações de plataforma onde ele vai ser implantado, o que é inviável em<br>
termos de gestão de projeto, por isso nenhum banco de dados faz isso<br>
(pelo menos o mysql e o postgresql não fazem). Posso estar enganado mas<br>
a única forma que vejo de viabilizar isso seria se o datacenter<br>
fornecesse patches pro banco de dados operar dessa forma. A Percona, por<br>
exemplo, é especializada em fazer esse tipo de coisa com mysql, mas eles<br>
cobram muito mais do que seria viável prum datacenter.<br></blockquote><div><br>Essa é a verdadeira beleza de um sistema UN*X ;)<br>É só uma questão de acessar um /dev/sda1 e mandar um ioctl() para desativar o cache do OS:<br>
<a href="http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html" target="_blank">http://dev.mysql.com/doc/refman/5.5/en/innodb-raw-devices.html</a><br><br>
</div></div>