Olá João, Joao escreveu: > Caros amigos me corrijam se estiver errado :) > Logicamente nao posso falar do firebird, pois se tratando de um bd que nunca > trabalhei nao posso analizar. mas em alguns aspectos que dissestes no mail > poderemos observar os seguintes pontos em relação ao postgresl. > > " - O processamento de funções no Post é mais lento que no Firebird, visto > que > no Post as funções são interpretadas e no FB, não. Isso se torna mais sério > em funções que possuem grandes "loops". > > - No FB, como as funções são compiladas, pode-se excluir o código fonte > destas do banco. Já no Post isso não é permitido. Isso gera um sério > problema > para os sistemas que possuem grande parte da suas "regras de negócio" > embitidas no próprio banco. " > > Primeiro ponto: acho que o postgresql é um dos poucos sgbds se nao o unico > que lhe possibilita essa flexibilidade de vc escolher uma linguagem que mais > se adapte a seu conhecimento e a uma determinada tarefa para que vc possa > escrever sua stored procedured. Isso nao e verdade, se vc estiver usando > linguagens como pl/pgsql,pl/pearl eu concordaria com vc pq ela é > intrepretada. Mas o postgres e tao MARAVILHOSO (hehehehe) que vc pode > escrever suas funcoes em C, e logicamente seria uma funcao compilada. Dica: > estude C e implemente suas funcões! te garanto q vai ser ate mais rapido no > q firebird! :) > > Pronto, chegou lá.
Eu tenho uma gama de linguagens procedurais que posso usar, posso por exemplo escrver funções em Delphi, VB, clipper, cobol, pascal e registrar como sendo feita em c, já que geram bibliotecas de vínculo dinâmico ou shared objects. Posso inclusive no PostgreSQL usar uma função que tenha sido criada para firebird. > - O processo de "update" é muito mais lento no Post. > > Queria ver dados de u]algum benchmark que mostrasse isso. -- Coutinho > Acho que isso se deve Multiversion Concurrenct Control MVCC, o que > possibilita menos bloqueios. Vc ganha um nivel incrivel de simultanedade nos > seus dados com MVCC. > > ----- Original Message ----- > From: "marlon david de souza" <[EMAIL PROTECTED]> > To: <[email protected]> > Sent: Monday, May 08, 2006 8:39 AM > Subject: [PostgreSQL-Brasil] Criticas ao Firebird > > > Bom dia a todos, > > Na última semana foi postado nesta lista algumas duras críticas ao > Firebird. > Eu participo, além desta lista, também na lista de Firebird e digo que lá > nunca ouvi ninguem criticar o PostgreSQL. > Não acredito que um software possa ser 100% melhor que um similar seu. > Sempre vai existir alguma coisa que o outro faz melhor ou mais rápido, e > isso > é bom pois incentiva a procura constante de melhorias. > Atualmente estou trabalhando na conversão de um sistema que roda sob > Firebird para este poder trabalhar também com o PostgreSQL. > Infelizmente com o Post tenho encontrado algumas dificuldades em > comparação > com o Firebird. Exemplos: > - Consultas usando a cláusula "limit" em funções selecionáveis (que > retornam > vários registros), mas sem "order by", precisam terminar para então o Post > retornar os dados. No Firebird esse processo é quase instântaneo, visto que, > assim que ele processa o primeiro item, é interrompida a consulta e > retornado > o dado. > - As consultas precisam terminar para então o Post retornar os dados. No > Firebird, a medida que a consulta vai sendo processada, já vai retornando os > dados. Isso tem um grande impacto nas consultas via Grid, visto que dessa > forma torna o sistema mais responsivo ao usuário. > - O processamento de funções no Post é mais lento que no Firebird, visto > que > no Post as funções são interpretadas e no FB, não. Isso se torna mais sério > em funções que possuem grandes "loops". > - No FB, como as funções são compiladas, pode-se excluir o código fonte > destas do banco. Já no Post isso não é permitido. Isso gera um sério > problema > para os sistemas que possuem grande parte da suas "regras de negócio" > embitidas no próprio banco. > - No FB eu consigo fazer um "explain analyze" em funções. Neste caso é > mostrado uma analize de cada consulta feita dentro da função, o que facilita > em muito a analize de performance. Já no Post isso não é possivel. > - O processo de "update" é muito mais lento no Post. > > Lógico que, assim como eu encontrei dificuldades com os itens acima, > encontrei diversas características que se destacam no Post. > O objetivo desse e-mail não é o de criticar o PostgreSQL, mas sim de > incentivar melhorias que podem tornar o PostgreSQL ainda melhor do que já é. > > > Sem mais, > > ---------------------- > Marlon David de Souza > Desenvolvimento > Sysmo Informática Ltda > _______________________________________________ > Grupo de Usuários do PostgreSQL no Brasil > http://www.postgresql.org.br > > _______________________________________________ > Grupo de Usuários do PostgreSQL no Brasil > http://www.postgresql.org.br > > _______________________________________________ Grupo de Usuários do PostgreSQL no Brasil http://www.postgresql.org.br
