Em determinadas aplicações utilizar recursos de software livre pode sair caro, abaixo um e-mail de uma empresa, cujo nome foi substituído por XPTO, relata a troca do banco de dados FireBird e suas respectivas razões.
Prezado cliente,
Alguns clientes XPTO que possuem o banco de dados FIREBIRD, estão enfrentando problemas devido às limitações deste banco, conforme relacionado a seguir:
- Não possui suporte;
- Limite no tamanho de databases;
- Grande incidência de corrompimento de bases;
- Recursos de administração do banco limitados;
- Problema de performance em grandes cargas no banco;
- Limitações tecnológicas do SGBD que causam problemas principalmente nos processos de criação e atualização de bases, e implementação de novas funcionalidades;
- Performance não atende os requisitos atuais do solução;
- Limitações para uso de multi-idiomas;
Por este motivo, a XPTO lança uma campanha de migração do banco de dados FIREBIRD para os bancos de dados POSTGREE SQL, ORACLE ou MS SQLSERVER.
Se a sua empresa possui os produtos XPTO rodando com o banco de dados FIREBIRD e deseja receber uma proposta de conversão de base de dados, por favor envie um email para emailoculto@xpto.com.
Li seu post 3 vezes e não pude deixar de ficar com a idéia de ‘WTF?!’ na cabeça.
Pô legal as outras companhias de BANCO de dados estão preocupadas com o FIREBIRD e já estão plantando falsas notícias, é só dar uma googlada e ver que isto tudo é mentira.
FIREBIRD FOREVER
O Firebird é bom para pequenas aplicações, quando o banco cresce ele deixa muito a desejar…
Como opção free eu prefiro o Postgres, que tem muitas funcionalidades e é bem robusto por ser free, até hoje não tive problemas com ele. Mas, se puder pagar, o SQLServer vale muito a pena, eu adoro.
Um abraço!
Já trabalhei com Firebird e hoje, infelizmente, trabalho com SQL Server. O Firebird é melhor em tudo, porém, precisa ser corretamente instalado e configurado, e em um servidor decente. Com certeza esses problemas citados são frutos da pura incompetência dos DBAs e desenvolvedores envolvidos. Post infeliz.
Bom… pelo o que podemos notar, programação é igual a futebol e religião… vc sempre vai defender o seu. Mas quando o assunto é solução de problemas dos clientes, todo o cenário deve ser analisado. Se a necessidade for quantidade de databases, replicações ou até quantidade de dados armazenados, sem sombra de dúvidas o SQL Server© é muito superior ao Firebird. Uma coisa que o Firebird tem de muito bom é sua ferramenta de gerenciamento, que possui tudo(tudo mesmo), o que vc precisa para configurar e trabalhar com seu banco.
Mas como eu citei acima, sempre vai ter quem discorde, e é por isso que temos uma gama de SGBD para que possamos avaliar e escolher o que melhor nos atende.
É como dizia minha vó “O que seria do azul se todo mundo gostasse de amarelo…”
Firebird em boas mãos e bem configurado supre muitas necessidades e não deixa a desejar em segurança. Falar que o Firebird não tem suporte soou muito estranho, eu não acho pouco a quantidade e qualidade do suporte dos membros da comunidade Firebird, porém, no entanto, se queres pagar pelo suporte, aceitamos também. Rs…
PostegreSQL é o que é mais próximo da perfeição, parrudo, veterano; e roda nas melhores plataformas deste universo; Só perde para Oracle, mas em caso de cluster[¹].
Uma coisa, “comprar” o melhor SGBD(OR) do planeta e não investir em DBA, você terá muitas dores de cabeça, para comprovar é só aguardar o tempo, quando teu banco tiver maduro e gordo.
MySQL (agora, MariaDB) => Só mais um banco para web.
SQL Server© => Only Window$; tô fora! ;D
[¹] http://pt.wikipedia.org/wiki/Cluster
Uso firebird faz uma década e nunca consegui corromper uma base, gostaria de saber como alguns DBAs (DBAs ?) conseguem isso.
Que post infeliz.
Testes feitos indicam:
Bem pessoal, em resumo…as diferenças são assustadoras:
Mysql – 1o. lugar…leva menos que um segundo para 1 ou 1000 registros.
Oracle – 2o. lugar…leva menos que 6 segundos para 1000 registros…porém quase 1 segundo para 1 registro
Firebird – 3o. lugar…leva menos que 0.5 segundo para 1 registro e quase 14 segundos para 1000 registros
Postgres – 4o. lugar…leva menos que 0.3 segundo para 1 registro e quase 31 segundos para 1000 registros
fonte: http://javafree.uol.com.br/topic-10357-Teste-de-Desempenho-mysql-oracle-firebird-15-postgres.html
Pessoalmente utilizo o firebird 2.1 sem problemas com sincronismo de dados num banco de apenas 3 gigas em ERP delphi. Já tive problemas de corrompimento em uma filial, e estou tendo problemas com lentidão de certas rotinas – contudo analistas já informaram solucionar o problema devido a uma falha de programação, o que deve melhorar a velocidade na próxima atualização.
Por mais filosófico que seja a paixão pelo software livre, para grandes empreendimentos certamente oracle ou mysql sem dúvidas.
Sucesso.
Vexe, para completar a disculção. Até 3 meses atráz eu era defensor ferrenho do FB, uso o 2.1, tenho uma pequena aplicação comercial, a 5 anos uso o FB sem nenhum problema, mas a 6 meses vivencio um problema, tenho dois clientes que ambos chegarão a casa dos 40MB de Tamanho de seus banco de dados. Até aí beleza, o FB continua atendendo os requizitos, porém estou com uma dor de cabeça… fazem 6 meses que um cliente, estava com poroblemas, tenho 60 clientes usando o mesmo sistema, mas neste cliente a base de dados alcançou os 40MB e começou a dar problema de corrupção do banco de dados. Todo o santo dia o banco de dados infla de seus 40MB para 90MB, 120MB, direto o cliente temq fazer um backup restore para voltar ao normal, pois ele começa a ficar lento e as vezes trava o micro todo, o FBSERVER.EXE começa a usar 100% de CPU, ja mudei para o classic server mesma coisa.
Levei o cliente no bico, por um tempo dizendo que era normal, aliás o processo Backup/Restore é rápido. Trocamos o servidor e continuou mesma coisa, aí ficou por isso mesmo, eu culpei o HardWare, pois em todos é o mesmo sistema e funciona 100%, até mês passado quando fui pego de surpresa por outro cliente que atingiu 40MB uma semana depois ele começou a apresentar o mesmo problema, virei o sistema pelo avesso para achar alguma GAFE, que poderia ocasionar o erro mas não encontrei NADA, Passei a gerenciar as Transações no próprio sistema, e NADA. Todo o dia estes dois clientes tem de fazer o BACKUP/Restore. Ja está causando mal estar entre Cliente/Fornecedor. Virei a Internet inteira procurando a solução e nada. Achei mais relatos de pessoas até com o 1.5 que tambem rodaram seus sistema por 3, 4, 5 anos e nunca apresentou problema, e do nada ele começou com o mesmo problema que o meu. Os entendidos que dão o suporte ao FB, dizem: ahhhh, faz um backup/restore que volta. Eu pergunto que tipo de solução é está? Não resolve o problema, apenas ameniza o problema. Infelizmente me decepcionei com o FireBird, vou tentar como ultimo recurso instalar o FB 2.5, quando sair, mas se não resolver vou ter que migrar a base de dados, chega a me dar arrepio só de pensar. Por hora até resolver meu problema, não recomendo para sistemas que possam usar um grande volume de dados. 40MB nem é grande, mas atingiu este tamanho no meu caso, ja era, é decretado o incomodo.
Abraços.
Se alguém tiver a solução, eu agradeço de coração, vai me poupar um trabalho lascado.
Duas perguntinhas:
Para quem defende: VOCÊ USA ELE COMO PRINCIPAL EM SUA APLICAÇÃO? QUANTO TEMPO? QUAL O TAMANHO DO BANCO?
Para quem Critica:
VOCÊ JA USOU??? QUAL O PROBLEMA QUE ENCONTROU??? AQUI ESTÁ RELATADO O MEU.
Abraços
Tópico totalmente ***SEM NOÇÃO***. Tanto o banco comentado aqui (Firebird), quanto, MySQL e PostGreSQL são excelentes SGDBs gratuitos q atendem com sobra quaisquer expectativas de grande a médio porte. Sugiro as pessoas que tiveram problemas com qualquer um destes, que primeiro estudem bem Modelagem de dados,limites do SGDB e do SO, segurança, e otimização de Queries, antes de postar esse tipo de comentário. É sempre mais fácil colocar a culpa no SGDB do que assumir uma deficiência técnica. A internet tá cheia de exemplos de Bases de Dados enormes com estes SGDBs com excente desempenho, sugiro que também pesquisem sobre o assunto.
ALmir sei que vai dizer que sou doido. mas te garanto o problema nao está no Firebird e sim na sua aplicação;
Apenas veja: SUA aplicação atinge 40 mb e da problema, vasculhe a net e procure sistemas prontos com bds e popule ou ja populado ou tente achar alguem que use firebird e verá que essa critica nao tem muito fundamento. Trabalhei em uma softhouse onde tinhamos dois sistemas um erp em sql server e sistemas de frente de loja em fb. problemas eram sempre proveniente de praticas de programação errada ou intervenção de usuario (no caso de corrompimento de bases; no mais tem base de dados com mais de 20 filiais e acima dos 6 gb (isso nao é megas é gigabyte) e aplicação executava brincando com a vantagem pr ousuario final de nao ter que desombolsar milhares de reais com licenças do bd.
Miha opiniao: sempre é mais facil botar a culpa no cachorro. rss
abraços.
Concordo com o comentário acima.
Tenho um sistema que roda em firebirdo com acesso a uma base de dados hoje com 2.2gb.
Quando a base chegou nos 2.0gb começou a ficar um pouco lento. A solução foi:
1-Fazer um backup restore (para reescrever os índices e limpar os dados dos registros ecluídos)
2-Trocar o servidor para uma máquina melhor.
Hoje roda normal…
Uso o firebird em mais de 200 clientes, alguns chegam a ter base de 30GB de tamanho e fazem consultas pesadas na web, o que posso dizer sobre o firebird é que ele vem melhorando a cada release que passa, quando migramos do 1.5 para o 2.1 a diferença em desempenho foi notável cerca de 40% com o mesmo hardware, e também caiu um pouco o fato de ficar rodando o gbak toda vez.
Uma coisa que posso dizer é o seguinte, na verdade na verdade muita gente confunde corrompimento da base de dados, com sujeira na base de dados, como indices, e tables temps que não apagam seus registros, então fazer um backup/restore a cada 15 dias é mais que recomendável não porque o banco ta corrompido mas sim porque ele vai acumulando sujeira e isso vai fazendo ficar um pouco lento. Um problema conhecido que existe no firebird 2.1.3 é que quando um usuário fecha com ctrl+alt+del uma transação corrente o sgdb mantem por dias essa conexão, causando alto uso de processador e memoria, o firebird eu digo que é um bom banco, mas você tem que conhece-lo muito bem, pois é cheio de armadilhas, usar linux como servidor é fundamental, saber aumentar os parametros de cache em disco para melhor leitura e gravação de i/o e usar todo recurso de hardware é fundamental, conhecer o firebird.conf de tráz pra frente para tunar o banco e conhecer sistemas de arquivos para saber qual tipo usar é fundamental. Por isso que muitos programadores fazem mal uso do firebird e diferente do MS=SQL que por padrão vem com uma configuração pronta, o firebird por default não é muito bem configurado, mas digo, bem configurado e com um bom linux customizado para o mesmo, e com o seu sistema bem programado você não terá dores de cabeças, e também sobre gbak/restore é igual MS-SQL que tem que reiniciar o servidor de tempos em tempos porque ele incha o famoso tempdb então faça um script que execute um backup/restore uma vez por mês que vai resolver o problema…
O firebird 2.5 promete várias correções, mas o melhor estar por vir no firebird 3 quando o super-classic server estiver maduro.
Do mais é um bom banco
Concordo com o “BOI”, o problema é que os programadores hoje em dia so sabem programar. Nao conhece SO e nem o proprio banco que trabalha. Ai como outros comentarios, é mais facil culpar o banco.
O Boi, falou com razão!!!!. Tenho aqui o meu Sistema de Controle de Ponto Rural. Está no tamanho de 4GB, já faz 4 anos. Uso o Firebird com a versão 2.1x., sem dor de cabeça e rodando tranquilo. Tenho uma rotina no sistema que faz backup/restore a cada 5 meses. Gosto muito do Firebird…
MySQL não tem (ou não tinha) um serie de requisitos de um banco de dados relacional.
Uso do Firebird, muitos ignoram uma instalação e configuração correta bem como a instalação de um servidor de dados.
A corrupção dos dados esta ligado a problemas além de quedas de energia a copia da base, questão de segurança, pasta da base compartilhada e outros detalhes parecidos.
O Firebird 2.5, em versão de teste final, é muito rápida, muito bem mais que a 2.1.
Possuo bases de vários clientes, alguns passandos dos 4GB. Corrupção a todo momento ocorre, e todos eles são problemas de usuários.
Lentidão ocorre, algumas vezes por problemas do sistema:
– SQL mal montadas
– Modelagem
– Driver de acesso
mas na maioria esta na estrutura do usuário
– Servidor compartilhado com outras aplicações.
– Rede
– Disco do servidor lento ou fragmentado.
– Falta de manutenção (backup e restore períodico).
Almir entra em contato comigo que eu o ajudo a resolver o problema, também já passei por isso.
Pode ter certeza de uma coisa, o problema é quem administra o banco ou quem constrói a aplicação, independente se o banco é x ou y …
cezar.atl@ig.com.br