Revista The Club Megazine, numero 87
[]'s Evandro Siqueira Programador Palas Informática ----- Original Message ----- From: Daniel Bastos <[EMAIL PROTECTED]> To: <delphi-br@yahoogrupos.com.br> Sent: Wednesday, April 20, 2005 1:26 AM Subject: Re: [delphi-br] Mais rapido Tenho que concordar com todos em partes.. É certo que tudo é passageiro, menos cobrador e motorista. Principalmente na nossa área. (Ontem aprendi Delphi, hoje, para me garantir no mercado, estudo java e DotNet). O que não poderia se diferente em relação a SGDBs. Ajudei a pouco tempo 2 mudanças do SQL Server para firebird, o que foi extremamente interessante. Um dos sistemas Client/Server utilizava acesso via ADO C/ SQL Server. Ajudei a fazer a migração, e constatei que o sistema estava bem estruturado e totalmente documentado(com modelos UML, Diagramas de classes, Casos de uso, e tudo que tinha direito). Não tivemos muito trabalho para fazer a migração. Ficou show de bola, claro que tive que reescrever muitas partes do programa, Stored Procedures e algumas queries (pq o firebird 1.x não aceita "select from select", mas a jente deu um jeitinho). Hoje roda muito bem e o cliente sai satisfeito e feliz da vida. Outro feito com DBExpress e SQl Server, mas estava totalmente zoneado. Com certeza deu muito mais trabalho migrar mas hoje tb funciona, mas não com o desempenho do primeiro. Não poderia-mos reescrever todas as partes senão faria-mos um novo. As vezes a mudança é só uma questão de estruturação e não de ferramenta de acesso. Vale ao desenvolvedor projetar o sistema com cautela pensando no futuro do sistema e calculando possíveis migrações, que, normalmente não são necessárias (ai, o melhor é usar todos os recursos que o SGDB nos dá). Voltando a pergunta original: Caro Aldinei Simões a resposta é mais compicada do que parece, por depender de inúmeros fatores. A minha sugestão é que se faça um pequeno sistema com as duas formas e se calcule o tempo de resposta de cada uma. Na revista clube delphi a algum tempo atraz(não lembro qual revista . Se alguem da clube delphi ler, por favor, poste o número) esplicava como identificar gargalos que poderiam comprometer o desempenho da sua aplicação. Não posso garantir, mas acho que o mesmo processo pode ser aplicado para sua solução. Caso faça este comparativo, não esqueca dos pobres programadores da lista carentes de tempo para fazer estes testes (como eu) e poste os resultados na lista. Abraço a todos Daniel A. Bastos On 4/20/05, Oséias Ferreira <[EMAIL PROTECTED]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Concordo com o Othavio. > Este negócio de portabilidade ainda é um sonho impossível. > Mesmo que use 400 camadas, além do sistema ficar uma trambolho, você > precisa cada vez mais de estações parrudas para fazer coisas bestas. > Ou você explora os recursos do Db, ou generaliza e perde performace e > aumenta a carga de processamento nas estações. > > Acho que é necessário ter visões, e pesar o que importa. > Se seu alvo é pequenos negócios, não vale a pena usar Oracle, pois > dificilmente será viável. Já empresas maiores, com uma boa conversa > resolve tudo. Não trata de "empurrar", o produto pro cliente, e sim > mostrar as vantagens que ele terá com o aplicativo (Diga-se de passagem, > não são poucas). > Agora a portabilidade, tem que ser milagreiro... > > O pessoal aqui, meio que endeusa o Firebird, ainda não entendi porque. > É um ótimo banco de dados, guardada as devidas proporções. > Quando alguém fala em Postgres, que também é publico, já vem logo com > pedras, que "é mais lento", "usa firebird", "firebird é free", etc. > O que eu nunca vi foi alguém fazer um comparativo, sem achismos entre os > dois. > No meu ponto de vista, em alguns aspectos, o Postgres está muito a > frente do Firebird, principalmente se estiver rodando sob *nix. > Comparar então Firebird com Oracle, já beira o absurdo. > É uma competição muito desleal. > Mas isto não vem ao caso... > > - -- > Oséias > > Rodrigo Othavio Farias escreveu: > > > > E viva o desempenho mediocre do sistema, e eu to falando de banco de dados > > de verdade, paradox, dbisam, access nao sao banco de dados, agora eu quero > > ver alguém ter coragem migrar de um Oracle pra um Firebird. > > A economia de dinheiro nao vale a dor de cabeça, já que o Firebird ainda ta > > engatinhando em relação a recursos se comparado a outros bancos com mais > > tempo de mercado, e nao estou dizendo que ele é ruim, só que ainda é novo e > > precisa amadurecer mais. > > > > E achar que vai mudar de banco sem reescrever uma linha de código sql é > > ingenuidade, por mais que se tente usar o Ansi SQL todo banco tem > > particularidades, é utopia achar que jogando toda a regra de negocio na > > aplicação vc nao ter trabalho numa migração, o que vc vai ter é um sistema > > pobre e lento, pq não aproveita todo o potencial do Banco de Dados e vai ter > > retrabalho quando for migrar já que nenhum banco é 100% compativel com o > > outro, nem o Sybase é 100% com o SQL Server, e olha que eles são feitos numa > > mesma base, estilo Interbase e Firefox. -- <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> Para ver as mensagens antigas, acesse: http://br.groups.yahoo.com/group/delphi-br/messages Para falar com o moderador, envie um e-mail para: [EMAIL PROTECTED] ou [EMAIL PROTECTED] Links do Yahoo! Grupos -- <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> Para ver as mensagens antigas, acesse: http://br.groups.yahoo.com/group/delphi-br/messages Para falar com o moderador, envie um e-mail para: [EMAIL PROTECTED] ou [EMAIL PROTECTED] Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/delphi-br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
