[Cascavel-pm] Banco de dados

Daniel Ruoso daniel em ruoso.com
Quinta Junho 28 02:03:21 PDT 2007


Qua, 2007-06-27 às 18:24 -0300, Nilson Santos Figueiredo Junior
escreveu:
> On 6/27/07, Luis Motta Campos <luismottacampos em yahoo.co.uk> wrote:
> >    Nem para tudo. Você não podia usar um subquery como uma tabela.
> A minha opinião é que, se você está fazendo isso, deveria ter criado uma view.

Ops, acho que você não está tendo uma dimensão dos usos que você
consegue arranjar para subqueries. Se eu fosse criar views para todas as
subqueries que fiz quando trabalhava com o PostgreSql, teria muito mais
views do que tabelas...

> >    Nossa, grande vantagem. É a única situação em que eu não me importo
> > com performance: quando estou desenvolvendo sistemas (e, portanto, sou o
> > único usuário do sistema)
> Sim, é uma grande vantagem considerando que é uma biblioteca de uns
> 300kb que você embedar em seus programas. Ao escrever aplicações
> desktop, ao invés de você usar alguma biblioteca tosca e limitada de
> armazenamento de dados você pode ter todos os benefícios de um banco
> de dados relacional. 
> E se o banco de dados for algo somente leitura, o desempenho continua
> ótimo. O problema do SQLite é que, pra escrita, ele dá um lock no
> arquivo inteiro (ou seja, no banco de dados inteiro). Por isso a
> utilização concorrente em aplicações com muita escrita fica
> prejudicada.

Hmmm... minha experiência com BerkeleyDB x Banco relacional embedded diz
que não ser um banco de dados relacional pode ser bom... Mas o banco
relacional naquele caso era o hsql em Java...

Posso ser só eu, mas aplicações mono-usuário mono-thread mono-processo
definem um universo muito limitado para mim. Pode até ser mono-usuário,
mas preciso pelo menos de "worker threads" (mesmo que sejam na verdade
worker processes), especialmente se for GUI.

> >    Apenas de boa parte dos sites de internet. Mas, normalmente, para
> > estas situações, o maior tempo de espera é a latência de rede, o que faz
> > a vantagem ser praticamente nula... eu acho.
> De fato, em sistemas web de grande utilização, o tempo de latência de
> rede é o menor dos problemas. Tudo mais costuma causar problemas de
> performance, menos isso.

E, na minha experiência, o mecanismo de replicação master-slave do mysql
é mais do que insuficiente para tornar o sistema escalável. São
necessárias soluções de clustering mais eficientes, como por exemplo
separar um conjunto de tabelas em uma máquina e outro conjunto em outra
(Coisa que o Mysql não faz, e o PostgreSql faz). E volto a repetir, se
voce usa o Mysql sem transações com MyISAM você pode até ter uma
performance significativamente melhor que o PostgreSQL, mas nesse caso,
não acho que você saiba realmente o que você está fazendo (MyISAM é uma
alternativa para casos muito, mas muito específicos mesmo). Mysql com
InnoDB fica mais ou menos com a mesma performance que o PostgreSQL.

Daniel



Mais detalhes sobre a lista de discussão Cascavel-pm