[firebase-br] firebird X postgreesql (leiam isso)

Walter Cruz walter.php em gmail.com
Qui Out 26 13:06:42 -03 2006


Olá a todos. Xá eu apresentar meus pontos aqui:

Eu uso mysql há um tempão. Uso PostgreSQL a um certo tempo.

Minha considerações sobre o MySQL:

é muito pobre em recursos e na questão dos padrões.

Por exemplo, imagine uma tabela tamanho, com uma coluna texto, de
tamanho varchar(10).

Segundo o padrão SQL, o seguinte comando deveria falhar:

INSERT INTO temanho(texto) VALUES ('texto muito grande');

Porém, no MySQL ele passa em branco e o texto é truncado. O Firebird e
o PostgreSQL seguem o padrão.

Uma época, num projeto que fizemos aqui, por causa da pressa,
colocamos uns campos que deveriam ser números como varchar no banco.
Fizemos a validação, mas novamente pela pressa, foi em JavasScript
apenas, e umas 20 pessoas usando navegadores muito antigos passarm por
ela sem problema. Nos relatórios disso, tínhamos umas contas dividindo
por essa valor. E o que aconteceu? Deu isso:

10000 / '20 pessoas' - sim, o cara escreveu pessoas ou sei lá o que na frente.

No MySQL, isso passou em branco e deu 0. Aliás, só percebi isso quando
estava testando  o PostgreSQL, migrei o banco pra ele e os relatórios
não funcionavam.

É óbvio que o banco não deve receber a culpa por uma modelagem
mal-feita e por desenvolvimento feito açodadamente. Mas, se esse for o
caso, saiba: seus dados estarão íntegros com o Firebird e o
PostgreSQL.

Fora a questão das engines - no MySQL vc cria a tabela e especifica a
engine. O MyISAM, que é o mais rápido não suporta chaves estrangeiras
nem transações. Se você usar o InnoDB, que suporta ambos, a velocidade
cai ( ou pelo menos, fica razoavelmente comparável ao Firebird e ao
PostgreSQL).

Sobre o PostgreSQL, é o banco que eu uso e recomendo.

Alguns pontos:

Foi levantada na lista a questão da dificuldade de administração. De
fato, o PostgreSQL requer uma administração mais assídua, com VACUUMS
e ANALYZE. Porém, há um certo tempo havia um módulo externo chamado
autovacuum, onde você o configurava e ele fazia isso segundo algumas
regras. Digo havia, porque não há mais: agora ele é interno. Já está
integrado ao banco.

A versão 8.2 está para sair, e apesar de não ser uma versão cheia de
características novas, ela é muito voltada pra facilitar coisas que
são um pouco chatas hoje em dia.

Uma das características legais é você poder ter triggers e stored
procedures em PL/Java, PL/Python,PL/PgSQL, PL/Perl e PL/Ruby, dentre
outras.

O otimizador do PostgreSQL é muito bom, e eles já tem implementados
alguns algoritmos de acesso a planos que o Firebird e o MySQL ainda
não tem (como hash join e hash aggregate). Na versão 8.2, os outer
joins vão ficar muito mais rápidos também. Outra característica bacana
é o suporte a índices funcionais.

Até um tempo atrás habia o problema da versão para windows rodar
emulado no cygwin. Embora isso não seja mais verdade desde o 8.0, a
performance ainda é abaixo dele rodando no Linux. Não sei se vai
igualar, mas na versão 8.2, mas foram feitas varias correções visando
aumento de desempenho.

Ah! uma coisinha engraçada: umas semanas atrás eu fiz um teste de um
milhão de joins.. criei uma tabela, com uma coluna de chave
primária/auto incremento e uma outra com valores sequenciais de 1 até
1.000.000 . Detalhe: sem usar índice.

Resultado: O Firebird levou alguns segundos. O PostgreSQL também. Após
algumas horas (aliás, eu deixei rodando de um dia pra outro aqui) o
MySQL ainda não tinha retornado...

Depois de criar o indice nos 3, o MySQL conseguiu me responder.

Minha suspeita é que o MySQL tenha feito um loop aninhado - para cada
um dos 1 milhao de registros, ele tenha feito uma busca nos outros 1
milhão de registros.

Não foi um teste muito cientifico nem nada assim, mas foi engraçado.

Então, resumindo: teste os dois, PostgreSQL e Firebird. :)

[]'s
- Walter




Mais detalhes sobre a lista de discussão lista