Firebird SQL: por que tão impopular? (e como melhorar a situação)

Firebird SQL: por que tão impopular? (e como melhorar a situação) 1 Recentemente iniciei um novo projeto no qual  precisei responder a questão: qual SGBD usar? Até então, vinha usando o MySQL para basicamente tudo (fou fanático pelo MySQL), porém, devido ao seu esquema de licenciamento e algumas restrições do próprio projeto, tive de ignorá-lo desta vez.

Foi quando me lembrei de um velho conhecido: o Firebird! Devo confessar: depois do MySQL, o Firebird se encontra em segundo lugar (talvez empate com o PostgreSQL) para mim.

Porém algo no Firebird sempre me incomodou: basicamente ele só é popular entre programadores Delphi. Mais interessante ainda: provávelmente o Firebird é mais popular aqui no Brasil que no resto do mundo (temos uma comunidade excelente por sinal: http://www.firebase.com.br/fb/).  Isto é natural, visto ser derivado do Interbase da Borland, cujo Delphi dominou o mercado de desenvolvimento no Brasil por vários anos. Porém, ao observar as vantagens do Firebird, o mistério referente à sua baixa popularidade fora deste grupo só aumenta:

  • Licença realmente livre: ao contrário do MySQL que te prende no GPL se você o quiser utilizar gratuitamente, o Firebird é de fato 100% livre para uso em aplicações comerciais.
  • O básico dos SGBDs “grandes”: stored procedures, triggers, conformidade com A.C.I.D., backups online, generators, integridade referencial,  suporte a diversos tipos de caracteres… todas as buzzwords estão presentes no Firebird.
  • Footprint mínimo: o Firebird possui uma versão embutida (uma única DLL) que ocupa menos de 1 Mb e não corta básicamente NENHUM recurso da versão completa!
  • Baixos requisitos de hardware: o bichinho pode ser executado em práticamente qualquer computador!
  • Multi plataforma: Linux, Windows, Mac OS, Solaris e outras
  • Suporte a
  • Performance razoável: não é lá estas maravilhas, mas fica entre o PostgreSQL e o MySQL
  • O projeto é ativo (e muito): apesar de sua baixa popularidade, o projeto é bem ativo. Em abril deste ano, por exemplo, saiu o beta da versão 2.5 do projeto.
  • Banco de dados fácil de transportar: este ponto é polêmico, mas o fato do banco de dados estar contido em um único arquivo torna suas bases de dados muito fáceis de serem transportadas (é possível ter um banco de dados com mais de um arquivo).
  • BDs com tamanho ilimitado: a limitação do tamanho do BD é definida pelo sistema de arquivos utilizado pelo sistema operacional. Se o seu arquivo superar este limite, basta dividir o seu banco de dados em mais de um arquivo.
    (o maior banco de dados conhecido possui 960 Gb de tamanho link)
  • 100% compatível com o padrão SQL 92
  • Inúmeras formas de ser acessado: basicamente é possível acessar o Firebird a partir de qualquer linguagem de programação. Existem diversos drivers ODBC, JDBC, ADO, PHP, .net, etc.

Tenho utilizado o Flamerobin para administrar o banco de dados do projeto e está sendo uma experiência muito agradável. Mas é muito triste constatar que desde que escrevi o meu conversor de banco de dados no formato Microsoft Access para Firebird em 2006 (MDB2FDB http://www.firebase.com.br/fb/downloads.php?categ=8) a situação não mudou em nada: Firebird continua sendo popular apenas por desenvolvedores Delphi.

Dado que gosto do produto, e acho um absurdo o seu problema de popularidade, penso que seria interessante listar algumas formas de ajudar o projeto. Segue minha lista de sugestões:

  • Usar o Firebird. Sério: experimente o bichinho. Caso não o conheça, você ficará surpreso com o fato de uma imensidão de recursos caberem em um software tão pequeno.
  • Caso já use o Firebird, você pode também fazer doações ao projeto.
    Eis o link: http://www.firebirdsql.org/index.php?op=ffoundation&id=contributions
  • É também possível ser um patrocinador do mesmo.
    Eis o link: http://www.firebirdsql.org/index.php?op=ffoundation&id=sponsor_howto
  • Caso sinta falta de alguma ferramenta para trabalhar com o Firebird, você pode criar a sua e distribuir gratuitamente, como eu fiz com o MDB2FDB.
    Se não for para distribuir gratuitamente, o simples fato de produzir algo para o Firebird já ajuda a aumentar a sua popularidade.
  • Escrever a respeito, e participar de grupos de usuários.

Claro, eu não poderia deixar de imaginar quais as razões pelas quais o projeto não é tão popular quanto o MySQL ou PostgreSQL:

  • Não há uma empresa de peso como Sun/Oracle ou IBM apoiando o projeto. Ele é mantido basicamente por voluntários e alguns patrocinadores.
  • O site oficial (http://www.firebirdsql.org). Parece futilidade, porém a primeira impressão que o projeto passa é péssima!
    O maior patrocinador do projeto é a IBPhoenix: uma empresa cujo negócio é o Firebird. Porém, mesmo esta ainda possui um site com péssima aparência.
  • O fato de ter sido desde o início associado ao Delphi. Com a decadência da ferraemnta, a popularidade do banco também foi junto.
  • Documentação pobre: ao acessar a documentação pelo site, você encontra diversos links voltados para as versões anteriores à 2.0 do Firebird. Além de que, é bem desorganizada.

Porém, estas razões são apenas um chute. Gostaria de saber agora de vocês as suas opiniões a respeito deste SGBD.

114 comments on “Firebird SQL: por que tão impopular? (e como melhorar a situação)

  1. carlsonwf

    Olha, depois de uns 6 anos trabalhando com o Firebird eu estou meio que sacudo dele. Já administrei pelo menos umas 300 bases de dados dos mais diversos tamanhos, tive muito problemas com bases corrompidas, inclusive esse final de semana tive o sábado perdido por causa de um desses problemas. Acho que esse foi sempre o ponto mais fraco do Firebird, sinceramente acho que está na hora de mudarmos de banco de dados aqui na empresa!!

    Responda

    Gnomo Reply:

    pra isso existe backup!!!

    aqui tbm tenho muito problema com postgresql em relação a base de dados ser corrompida, mas se o problema for queda de energia ou algo similar ai não adianta bota a culpa no coitado do firebird

    Responda

    Carlos H. Cantu Reply:

    Trabalho com Firebird desde a época do “InterBase”, e NUNCA tive uma base de dados corrompida. Com certeza algo está errado aí.

    Responda

    Juliano O. Barreto Reply:

    Também trabalho com o Firebird e Delphi 7 vários anos e só tive problemas no começo, quando estava em fase de aprendizagem. Mas os meus problemas foram mais relacionados ao modo como criei o banco de dados, nunca tive motivos para culpar o banco de dados Firebird.

    Responda

    Leonardo Freitag Reply:

    Também trabalho com firebird desde 2003, e tive apenas 2 problemas de banco de dados corrompidos, mas as condições em que o servidor rodava eram precárias.

    Responda

  2. Dario

    Olha tambem trabalho com Firebird ha 9 anos e não tenho problemas, e olha que no dia dia trabaho com Sql Server e postgree, e acho que o firebird para aplicações pequenas e muito mais produtivo, faço tudo rapido e simples, sobre o problema de corromper nada que um bom no-break solucione..rss

    abraços a todos..
    att
    Dário Tavares

    Responda

  3. Marcos

    O fato dele não trabalhar com Log, mas com versionamento faz com que seja mais difícil recuperar de uma corrupção. Por um lado torna ele o mais rápido pra inserções concorrentes, por outro torna o que mais facilmente se corrompe.

    Responda

  4. Fábio

    Já trabalho com o Firebird a alguns anos, nunca tive problemas com ele, problemas de corrupção geralmente estão relacionados com o servidor ou configuração, ultimamente estou trabalhando com um banco de dados de +- 4.5 gigabytes, 24×7 sem nenhum problema, utilizo a ferramenta IBExpert para gerenciamento do banco 100%.

    Abraço a todos…
    Fábio…

    Responda

  5. Marco

    Trabalho com o Firebird faz 9 anos em projetos próprios e com Oracle, Informix, SQL-Server e Sybase nas empresas que trabalhei, o Firebird é o melhor de todos em diversos aspectos, nao tem nenhum argumento que justifique pagar por SGDB comercial.
    Nesses 9 anos nunca tive base corrompida e uma delas tem milhoes de registros inseridos.
    As dicas sao, voce colocou o Firebird no mesmo hardware requerido pelo Oracle? Nao adianta falar que o FB corrompe a base e o oracle nao se voce colocou ele num micro Frankstein Windows XP e o Oracle num Servidor parrudo com Unix e tal.
    Desempenho? o client do Oracle usa quase 1 GB no disco, feito em Java. Na pratica o FB fica mais rapido se estiver no mesmo HW que o Oracle justamente pela ineficiencia e fome de recursos para acessar o mesmo (fora ter que configurar o tnsnames.ora).
    Agora, a facilidade e produtividade do Firebird sao inquestionaveis, o banco é facilmente transportável, voce instala um servidor em 5 minutos sem precisar configurar nada, acessa varias bases sem complicação de ter que configurá-las no server, mas o maior motivo é a linguagem SQL (triggers e procedures) dele ser muito superior, o que nele torna desnecessario ter que usar varios xunxos como eu tenho que fazer no oracle e sql-server (tabelas temporarias por exemplo nunca precisei no firebird).
    Meus projetos estao em Delphi e .net acessando o Firebird tranquilamente.
    Melhor jeito de colocar o FB é num servidor Linux somente com o FB e com Journaling no sistema de arquivos escolhido (aí nem precisa no-break) e forced writes ligado.

    Responda

  6. Felipe Jaekel

    Troquei o Firebird pelo MySQL pelos seguintes motivos:
    – Melhores ferramentas para MySQL (Admin, Query Browser, Workbench, etc)
    – Necessidade de criar um Generator e um Trigger para ter um ID incremental no Firebird. O Flamerobin ajuda, mas ainda assim tenho que escrever mais código nas minhas classes persistentes (Hibernate + JPA)
    – Principal motivo: pelo menos na versão 1.5.5, toda vez que vou criar uma Foreign Key ele não permite, alegando que uma das tabelas está em uso, sendo que elas acabaram de ser criadas. Só conseguia criar a bendita da FK parando o banco todo. Isso é simplesmente inviável em produção, especialmente na Web, plataforma na qual estava usando o Firebird (não foi uma escolha de projeto, a base de dados é legada, na verdade atualmente trabalho com os dois SGDB, porém as novas funcionalidades do sistema utilizo MySQL)

    Responda

    admin Reply:

    Já eu troquei o Firebird pelo MySQL em alguns projetos pelo fato de no MySQL eu poder criar relacionamentos entre bancos de dados distintos de uma forma mais fácil.

    Também, na época, por causa da performance. Só que cada caso é um caso: há situações nas quais o Firebird é uma mão na roda (aliás, não uma mão, mas braços!). O fato de possibilitar o transporte fácil dos bds também é algo a ser levado em consideração.

    Com relação ás ferramentas, devo discordar. Na realidade, acho as ferramentas do Firebird superiores às do MySQL.

    Responda

    Diego Reply:

    Utilizo a versao 2.0 e migrando para a 2.1 nesse momento, em 6 bases de dados replicadas de 10 GB cada. Ja tive problema de corromper a base, mas foi devido a falta de energia e nada que as próprias ferramentas do banco nao dessem jeito.
    Existem ferramentas muito boas para o firebird, é o caso do ibexpert que na versao personal que é gratuita já é suficiente para a grande maioria das operações no banco e muito superior as ferramentas do mysql.
    Utilizo a versao 2.0 e 2.1 do firebird, esse problema das foreigns keys se existia na versao 1.5 nao existe mais.
    Mas com certeza poder usar o banco gratuitamente sem limitação a aplicações comerciais foi uma das principais razões de escolha.

    Responda

  7. Joel Wallis

    Nunca tinha usado outro db a não ser MySQL e Access :P
    Baixei o Firebird pra ver como é e estou baixando esse Flamerobin aí pra ver como é.

    Responda

    Fabio Reply:

    Ola

    Tenho preferencia pelo IbExpert, versão Free.

    Pode experimentá-la e definir sua opinião.

    []´s

    Fabio

    Responda

  8. Giovani

    O Firebird vem me atendendo muito bem por mais de 5 anos sem problemas. É um SGBD execelente e com um enorme potencial para melhorar ainda mais. O único grande defeito dele é em questão a política de segurança, onde qualquer um que tiver posse do arquivo pode abri-lo com facilidade em outra maquina. Confio que isso vai ser resolvido no futuro.

    Responda

  9. Luis

    Descobri esse artigo em uma lista de Firebird.

    Estou estudando-o aos poucos, no tempo livre que não é muito.
    Tenho um sistema completo (integrado) que funciona a 9 anos em VB6 + ADO + MSAccess (MDB), em clientes com unidades de acesso remoto via (Remote desktop ou Terminal Server), mais de 24 usuários simultâneos, porém não é uma aplicação crítica e o banco em 8 anos atingiu 40 MB.

    Expliquei isso só para dizer que nunca tive problemas com o MDB em rede, pois toda codificação do sistema é cuidadosamente realizada para evitar qualquer problema, com acessos rápidos e término da conexão o mais rápido possível, assim tive sucesso em vários clientes.

    Agora minha necessidade mudou, tenho empresas grandes interessadas, onde o Access já começa a não ser mais viável, seja pelo volume de acessos, de dados ou pela comunicação remota, então preciso migrar meu sistema.

    Pesquisando ví as dicas do FB, porém quanto mais leio sobre ele, mas preocupado fico em migrar. Vejo a cada dia mais problemas na lista que participo só como leitor para conhecer.

    Há uma falta real de material para ele que não seja para Delphi (meu caso que uso VB6), o pessoal usa muitas siglas nos artigos e fóruns, dificultando identificar o que é cada coisa, e geralmente é tudo ligado ao Delphi.

    Até hoje tenho muita dificuldade de saber como fazer e de que forma, o trabalho de criação, comunicação do meu sistema com o FB. Baixei a versão 2.1, mas ainda não instalei, pois se vou começar acho que tem de ser melho mais atual, já basta meu VB6 que foi descontinuado, mas ainda resolve muito.

    Concluíndo, os problemas que vejo no FB seguindo os próprios comentários em sites e fóruns, que não tive ainda com o Access:
    – Corromper facilmente pelos relatos, parece até mais fácil do que um MDB (cruzes)
    – Erros e problemas inexperados que ocorrem do dia para noite sem motivos aparentes, em sistemas já rodando a anos. Isso está cada vez mais frequentes, principalmente para quem migrou para v.2.1
    – O banco não pode ter uma senha diferente para o Administrador SYSDBA que impeça o Linux ou o ADMIN de acessar um banco criado por mim, isso é um grande problema.
    – Comprei dois livros, mas quanto mais leio, mais dúvidas tenho.
    – Concordo aqui com o autor do artigo, falta um material de qualidade, bem explicado e generalista, não específico para Delphi. Ou seja, algo que permita o uso por qualquer inicialte facilmente.
    – os sistes deles são péssimos mesmo, desorganizados, os materiais não tem controle de versões, dificultando um iniciante de saber se funciona na versão que baixou ou não.
    – os exeplos são geralmente para versões antigas, v.1.0 ou até 1.5, parece que esquecem de atualizar ou fazer coisas para as versões novas, isso demonstra uma falta de atualização e aparente um “Abandono” da ferramente para quem inicia.

    Acho que a idéia e a ferramente são ótima, porém mau administradas e quem tem conhecimento não procura compartilhar para mudar esse quadro. Sou suspeito para falar, mas vejo uma grande diferença em relação a comunidade Firebird em relação a VB, quem usa VB tem um fasto material, com atualizações permanentes, exemplos diversos para vários bancos, com muitos artigos em vários sites e todos free. Apesar de não ser realmente um banco de dados, o access é muito utilizado e defendido pela simplicidade e facilidade de uso. Assim acho que deveria acontecer com o FB, ser mais simples e com os desenvolvedores que conhecem melhor os recursos, dificuldades e soluções, compartilhar isso com artigos, etc…

    Responda

    Sérgio Reply:

    Um banco que em 8 anos cresceu apenas para 40 Mb até o XBase resolveria, não é mérito nenhum do Access.

    Responda

    admin Reply:

    Pois neste mundo estranho já vi banco Access com mais de 1 Gb acessado por uma rede de 400 computadores (detalhe? com 40 conexões simultaneas).

    Funcionava? Sim.
    Rápido? Como uma pedra
    Dados corrompidos? Nunca.
    Solução boa? Péssima, mas como disse, funcionava.

    Responda

    Sérgio Reply:

    Banco de dados em Xbase (velho e bom clipper) com mais de 600 usuários ao mesmo tempo acessando (uma matriz e dezenas de filiais espalhadas por diversas cidades/estados)

    Funciona ? SIM
    Rápido? Claro !!!
    Bonito ? Não
    é a melhor solução ? Não

    Motivo de ainda não ser mudado: Preguiça do desenvolvedor (eu o conheço) – aquela velha desculpa: está funcionando então está bom.

    Responda

  10. Sérgio

    Ao autor,

    Caro autor, o link do MDB2FDB está quebrado.

    Responda

    admin Reply:

    Sim, eu sei. Estou trabalhando em uma nova versão do exportador que deverei disponibilizar em breve.

    Responda

  11. Frederico

    Olá pessoal, estamos nesse exato momento aqui na empresa tendo que decidir qual banco de dados utilizar em um determinado aplicativo, e essa discussão caiu como uma luva.
    Temos um software desktop em Java que funciona a cerca de 2 anos e meio com o banco de dados PostgreSQL. O banco em geral sempre nos satifez bem, vez ou outra ocorreram alguns pequenos problemas, mas nada grave. Nossa base de dados é leve, com no máximo 100 MB e o acesso à base ocorre geralmente por 2 à 6 usuários simultâneos. Sempre tivemos a impressão de que estávamos usando um canhão para matar uma mosca ao optar pelo PostgreSQL… Porém, agora este canhão está se mostrando um tanto quanto pesado pra carregar. O caso é que a forma de distribuição do software está sofrendo algumas alterações, antes atendíamos a poucos clientes e acabávamos atuando tb como “DBAs” para eles, no entanto agora a idéia é tornar o software trivial de ser distribuído e instalado, o mais simples possível.
    A primeira idéia que nos veio a cabeça foi usar o Firebird, mas, cada vez que pesquiso sobre ele mais vejo situações de migrações opostas (Firebird -> PostgreSQL).
    Outro problema é que o Firebird parece só aceitar conexões múltiplas se for instalado como servidor, se for embedded só aceita uma única conexão. Isto procede?
    Para nós seria interessante que o banco fosse embutido e, caso houvessem mais máquinas para acessar, aí sim nossa aplicação o iniciaria em modo server.
    Estou pesquisando outros bancos também, um que me parece permitir acessos múltiplos mesmo em modo embutido (no caso dele seria modo mixed), é o H2. Mas estamos fazendo os primeiros testes com ele e não sei ainda se esse banco seria confiável.

    Responda

    admin Reply:

    No seu caso, o Firebird cai como uma luva.

    Nunca tentei usá-lo no modo embutido como sevidor, porém, se for para acesso somente local, o servidor embutido é incrívelmente bom (só tem um problema na minha opinião: até aonde sei, é Windows only)

    Já para acessos simultâneos, o ideal é instalar o servidor mesmo.

    Responda

    Frederico Reply:

    Vou fazer alguns testes nos próximos dias tanto com o Firebird quanto com o H2 e volto aqui pra postar o que puder inferir.

    Responda

  12. Wagner Porto

    Olá,
    eu administro desde 2002
    um total de 125 bancos de dados dos mais
    variados tamanhos em Firebird.
    Comecei com o IB6 depois FB 1, 1.5, 2.0 e estou com 2.1,
    A cada nova versão para mudar é preciso apenas um Backup na versão antiga / Restore na versão nova e pronto.
    O Servidor é um P4 com 1GB ram e Window 2000 Server em regime 24 x 7, com 1 reboot todos dias as 07:00 da manhã.
    Durante esse periodo, não tive nenhum problema com corrupção de dados, mesmo temdo mais consultas do que Insert/Update.
    As aplicações que acessam ele são diversas, algumas em Delphi, Java e Python.

    Para mim é a melhor solução.

    Responda

  13. Fernando Romulo

    Como eu programei primeiro em Delphi eu tive a felicidade de conhecer o Firebird, agora como programador Java usei ele apenas em projetos desktop. Tenho a impressao de uma demora na hora de subir a aplicacao, principalmente qdo o banco estava com muitos registros, mas depois funciona tudo blz…
    Aqui nunca corrompeu, ainda bem… :)

    Responda

  14. Joel da Rosa

    Olha, desde que comecei a programar uso Firebird (iniciei com 1.5), e também já usei outros SGDB, como MySQL, Access, dBase. Mas nunca tive resultados tão expressíveis como no Firebird, entre as inúmeras facilidades e qualidades já expressadas pelos amigos acima enalteço ainda mais estas:

    * 1 único arquivo para a base.
    * Liberdade de S.O.
    * Comunidade de suporte super ativa.
    * Equipe de desenvolvimento super ativa.
    * Inúmeras ferramentas internas e externas para gerenciamento.
    * Inúmeros drivers para conexões com diversas plataformas de desenvolvimento.
    * Instalação Fácil e sem configuração.
    * Sem limitação de tamanho.
    * Backup on-line.
    * e poderia continuar escrevendo mais umas 10 folhas de qualidades…

    Estou atualmente usando o firebird com Delph, mas já estou começando a usar em Java também, e não estou encontrando nenhum problema nesta mudança.

    E uma última coisinha que é uma nova funcionabilidade que são as novas tabelas de monitoramento do banco de dados, onde é possível saber tudo que está acontecendo no seu banco de dados.

    E gente é um banco 100% livre.

    E eu confio muito no banco, e vocês podem conferir, 99.99999% dos problemas que acontecem com um banco de dados em Firebird tem a ver com problemas elétricos, de servidor e até mesmo de má uso do mesmo.

    Eu aconselho o seu uso.

    Responda

  15. Felipe Cypriano

    Eu não gosto do Firebird. Aqui na empresa tenho 3 bancos, o maior tem só 750mb o que é muito pouco mas em 1 ano esse tamanho era metade disso.

    Alguns problemas que acontecem aqui e que atrapalham a produtividade:
    – Não é possível alterar nenhuma estrutura do banco quando tem usuários usando. Por exemplo, preciso dar um ALTER PROCEDURE para corrigir uma coisa mas o FB só deixa quando eu desconecto todos os usuários. (Na maioria das vezes preciso dar um shutdown não adianta só os usuários fecharem a app)
    – Tenho uma app web que acessa esse banco e para modificar alguma coisa é preciso parar o servidor (fechar o pool de conexões)
    – Se uma estação estiver no meio de uma transação e a mesma der algum problema como reiniciar sozinha, a transação continua aberta no banco causando lock conflict e só da pra resolver, novamente, fazendo um shutdown no banco.

    Como a app usada aqui não foi bem feita os outros problemas que acontecem são problemas de má programação. E como não confiamos no FB são feitos 3 backups completos ao dia, ainda bem que a base é pequena.

    Responda

  16. Ricardo

    Nas minhas aplicações iniciei utilizando o access. Mas conhecendo o firebird, me adaptei mto com as suas vantagens. Gostaria de aproveitar e falar q o download do aplicativo MDB2FDB se encontra indisponível.

    Responda

  17. Jaider

    Eu não trabalhava com Firebird, há um ano ingressei em uma empresa que utiliza apenas Firebird, e hoje realmente encontro muitas vantagens em relação ao mysql ou postgre, por exemplo as SP e Triggers. E em questão de desempenho ele não fica muito atrás também.

    Quanto às bases corrompidas, em 1 ano de trabalho, cerca de 30 bases rodando 24/7, apenas uma vez presenciei uma base corrompida, e o gfix resolveu sem problemas.

    Nunca tive problemas de não conseguir atualizar as procedures ou triggers e ter de derrubar os usuários. Geralmente isso ocorre quando algum outro desenvolvedor está com a mesma aberta no IBExpert.

    Já o dead lock realmente acontece, em alguns casos temos de reiniciar o serviço ou esperar cerca de meia hora para que o firebird derrube a conexão que ficou aberta (graças aos Ruindows dos usuários que acabam travando no meio de alguma transação).

    Em geral o Firebird deveria ser mais elogiado e valorizado, ele é muito bom mesmo, porem pouco utilizado (as vezes parece até preconceito dos novos desenvolvedores).

    Parabéns Autor pelo ótimo artigo.

    Responda

  18. Selmo Almeida

    Eu trabalho com o firebird desde a versão 1.0. Atualmente utilizo o ibobjects para o acesso. Não tenho o que reclamar. O firebird tem muitos recursos, cito como exemplos o evento disparado pelo banco para as aplicações conectadas e o shadow.
    Com relação à base corrompida, é bom ficar de olho em duas coisas: Falta de energia e problema de alteração na estrutura da tabela sem observar dados existentes. Ex: mudar um campo para não nulo com linhas anteriores com nulo.

    Responda

  19. Gurgel

    – Corromper facilmente pelos relatos, parece até mais fácil do que um MDB (cruzes)

    Discordo, o que acontece com bancos como oracle e postgres é que eles trabalham com logs. São mais robustos contra corrupção, mas mais lentos que o versionamento. Eu lembro que antigamente corrompia muito também quando a qualidade da rede fosse ruim, mal montada. Hoje em dia isso não ocorre tanto… mas é piada ver cabo de rede passando trançado com cabo de força.

    – Erros e problemas inexperados que ocorrem do dia para noite sem motivos aparentes, em sistemas já rodando a anos. Isso está cada vez mais frequentes, principalmente para quem migrou para v.2.1

    Isso é migração mal feita. Na hora de trocar de versão tem que fazer o backup e o restore. Backup na versão antiga, restore na nova. Sempre que um release novo é lançado eles avisam da mudança de ODS. (onDisk Structure). Mudou ODS não fez backup e restore vai ter problemas bizarros mesmo. Isso vem desde o interbase x.

    – O banco não pode ter uma senha diferente para o Administrador SYSDBA que impeça o Linux ou o ADMIN de acessar um banco criado por mim, isso é um grande problema.

    Pode sim, voce pode configurar inclusive na sua máquian e depois fazer o deploy da security2.fdb.

    Sobre banco embarcado realmente é para uma conexão só… para funcionar multiusuario tem que instalar servidor. Mas o instalador é trivial e ainda voce pode puxar o script inno e customizar.. trocar arquivos etc. Qualquer um que instala software em windows (next next finish, instala o firebird). E ainda tem mais! As maiores distribuições linux hoje tem apt-get firebird, urpmi firebird etc…

    Responda

  20. ncc_star

    Realmente o Firebird é muito bom e prático, mas a respeito de corrupção acontece, mas em todas as vezes que eu corrigi o problema se encontrava em falta de nobreak, hardware ou vírus que detonava a maquina. Ou seja, situações que corromperia qualquer banco de dados.

    Responda

    nmpvt Reply:

    Exatamente… só aparecem estes casos de corrupção do firebird por ele ser tão prático de usar que acaba sendo utilizado em pequeninos projetos, onde as demais opções seriam Paradox, Access e “tranqueiras” do tipo.
    Com isso, o hardware também é ruim, sem no-break (ou com bateria fraca) e o SO normalmente é WinXP (não duvido que tenha até win98).
    Agora, quantas máquinas winXP sem no-break e cheias de vírus rodam uma base de dados Oracle, Postgree ou mesmo MySQL???

    Firebird não é o melhor banco do mundo… mas, e o que seria um bom banco? Não seria aquele que melhor atende cada caso? O Firebird é uma ótima opção para os casos ao qual ele foi projetado. Sistemas de pequeno e médio porte.

    Responda

  21. carlos

    A forma que as defesas e ataques são postadas aqui, demonstra bem o que acontece no mundo da informatica, ninguém quer tentar , os defensores sempre usaram, os detratores não pussuem argumentos fortes.Cada um senta no seu cavalo e cavalga, só muda quando o cavalo morre.Vamos esperar os detratores do firebird mudarem de time , quando que tiverem que pagar o MYSQL.
    fire iron

    Responda

  22. Cláudio Pessoa.

    Interessante, tenho lido aqui muita reclamação sobre corrupção da base de dados, mas acredito que deva-se a uso incorreto, como copiar a base enquanto esta em uso. Tenho mais de 60 bases (em cliente diversos, maquinas diferentes, rede estranhas, etc) a mais de 2 anos e NUNCA tive corrupção de base. As que aconteceram foram por culpa minha, por fazer manutenão com usuarios logados ou não fazer backup/restore em mudança de versão.

    Sobre a questão do tamnaho “inchado”, isso é culpa do programador que desenvolveu o aplicativo, mas mesmo nestes cacos um simples backup/restore na base, em segundos, limpa toda a sujeira (registros apagados, triggers orfãs, etc).

    Responda

  23. Diógenes Raizel

    Trabalho com Firebird desde a versão 1 e nem sei usar as ferramentas de restauração de bases corrompidas, pois nunca precisei delas.

    Responda

  24. Costa

    Trabalhei muito pouco diretamente com o firebird, mas orientei um trabalho de conclusao de curso de graduação que fez um comparativo entre MySQL e Firebird. No computo geral na época, o firebird obteve melhor resultado, principalmente porque o MySQL nao havia implementado uma serie de recursos mais avançados de que o firebird ja dispunha. Em ambiente web o MySQL (usando tabelas MyISAM) ganhou, mas quando se tratava de desktop, o firebird foi o campeao.

    Responda

    admin Reply:

    É o que digo sempre Costa: uma GALERA menospreza o Firebird sem saber do que está falando.

    Responda

  25. Julio Cesar Develis

    Tenho empresa com sede em maceio/al, onde tenho uma carteira de clientes significativa. Uso o firebird a 5 anos e vejo nele um excelente banco de dados para pequenas e medias empresas. Isso tudo pela facilidade de instalação e quase nenhuma manutenção requerida. Mas estou mudando meu perfil, preciso atingir empresas de grande porte, onde o firebird ja não poderá suprir de segurança e desempenho neste caso. O principal problema é a ausencia de clusters, onde nao poderei balancear a carga de dados entre varios servidores. O banco free mais indicado é o PostgreSql, muito mais que o MySql, pois o mesmo possui dominios e funcoes, inexistentes no mysql.
    Gosto do firebird, mas para pequenas e medias empresas…

    Responda

  26. Fernando Medeiros

    Problemas com FIREBIRD ?
    Eu não sei qual o motivo de inventarem tanto problema para esse magnífico banco de dados.
    Trabalho com ele já faz uns 10 anos. Já trabalhei com interbase e nunca tive uma base corrompida, muito menos com FIREBIRD.
    Gostaria de saber pq uma base de dados FIREBIRD se corrompe, se isso realmente acontece, por mim é devido a fatores externos como a falta de um nobreak.

    Responda

  27. Fernando Medeiros

    Não sei que tanto o pessoal fala que o banco de dados se corrompe. Uso o firebird faz anos, e nunca tive essa surpresa. Creio que se há corrompimento da base, é por fatores externos. Um nobreak com certeza resolve o problema. É leve e confiável. Nunca precisei mudar de banco de dados pois pra mim, o firebird é completo, banco do brasil, caixa e outras empresas que o diga.
    Agora, não vão querer comparar um oracle com o firebird não é pessoal ? (me ajuda ai)

    Responda

    admin Reply:

    Eu também nunca vi uma base Firebird corrompida.

    Responda

  28. Leonardo

    O Firibird, para Web não é tão eficiente quanto ao MySQL, acho que colocando os prós e contras de cada um, eles se equivalem.

    O PostGreSQL é tudo de bom , é um elefante de forte, e como todo elefante, tem boa memória e muito inteligente rs :) (desculpem o tracadilho) é bem rápido tbm, em alguns teste o PostGreSQL, foi 40% mais rápido em acesso, gravação do que Firebird e MySQL.

    Mas corrupção de base de dados em Firebird , só que se tiver com pau na maquina, uso o firebird desde a sua primeira versão, e os poucos problemas que já vi (eu faço suporte para um monte de empresas) é problema com hardware, elétrica , hidráulica ops… hidráulica não..kkk mas falando sério, um cliente andou danificando base dados firebird, mas era o HD que estava detonado, e outro foi rede elétrica que fazia o nobreak surtar (talvez até problema no nobreak), e cortar energia o tempo todo.

    Tirando isso o FB é muito bom mesmo, para web, precisa melhorar um pouco a perfomace, o protocolo dele para web conversa muito com o servidor e o cliente…

    Mas a questão do BD ser em um arquivo só, é até mais tranquilo, porque a pasta onde está o .fdb (EXTESÃO PADRÃO DE UM ARQUIVO FIREBIRD), se quer precisa estar compartilhada.

    Basta fazer a conexão usando:
    ip:d:\pasta\arquivo.fdb

    ou se for na web
    meudominio.com.br:d:\pasta\arquivo.fdb

    O Resto é só festa.

    Uma coisa chata mesmo que já foi falada e concordo, é o fato de fazer os relacionamentos (foregein), ou alterar uma procedure, tem que derrubar todo mundo e entrar novamente, para evitar problemas.

    A grande vantagem do FB é a facilidade de distribuir o seu aplicativo depois, qualquer usuário instala a bagaça depois, só ir no next,next,next…. tem como copiar a pasta do FIREBIRD, e fazer a instalação do serviço do firebird , liberação de porta de firewall (3050) tudo via linha de comando, embutido dentro da instalação.

    Responda

    admin Reply:

    Excelentes pontos Leonardo, concordo com você em todos eles!

    Responda

  29. Fernando Medeiros

    Essa é uma boa hora de tornar o firebird mais popular divulgando a campanha “MIND THE BIRD”. A campanha divulga o lancamento da versão 2.5 do FB. Maiores informações no site da firebase e no site oficial da campanha http://mindthebird.com (ingles).

    Estou divulgando no meu blog também. Façam o mesmo.

    Responda

  30. joao

    Acho esse banco de m…. devia deixar de existir logo.
    Nao sei pq o pessoal aiinda usa essa desgraça.

    Responda

  31. Ricardo Guilemond

    Utilizo o Firebird tanto em redes locais como remotas desde a sua primeira versão e também utilizo MySQL há 3 anos. Nunca tive problemas com o Firebird, só sinto falta de melhores programas de manutenção destes dois Banco de Dados.
    Aliás, no caso do Firebird, uma vez tive problemas com uma placa de rede que jogava lixo nos registros do Banco de Dados, pude recuperar o Banco de Dados Firebird sem maiores problemas. Portanto, corrupção de dados no Firebird só se for mal utilizado ou se for por fatores de hardware, e, se for por hardware então qualquer Banco de Dados pode sofrer avarias. A diferença está em qual a recuperação será mais ou menos tranquila.

    Meu maior Banco em Firebird possui 900 mil registros e há consultas que podem trazer em (“demorados”???) 45 segundos um lote perto de 100 mil registros numa query. Utilizo ADO para fazer a ligação do Firebird à minhas aplicações Delphi.

    A meta de consulta acima tem um tempo muito superior no MySQL, e ainda estou tentando ver como posso melhorar isto. Em queries com consultas mais reduzidas o tempo do MySQL é bem menor que o Firebird. Mas na medida que a consulta vai ficando gigante o Firebird tem melhor performance.

    Estou planejando parar de fazer sites em PHP e Java por causa do excesso de tempo na programação e pela falta de melhores recursos para um “debug” e segurança interna do BD. A partir de agora vou utilizar Delphi + nTier + IIS obviamente em servidores Windows, pois tenho tido maior aproveitamento do tempo de programação, já que o Delphi me permite agilizar com o debug e me dá maior confiança na segurança interna do BD.

    Além disso o Firebird combina muito bem com Delphi nas diversas plataformas. Quem sabe faz, e sabe que o Delphi é a ferramenta mais rica em biblioteca de programação. Vivem falando que o Delphi vai acabar (palhaçada!) e vivem tentando dizer que PostGresql ou MySQL são melhores que o Firebird. Bom, melhor que Firebird só o incrível MS-SQL, mas este é caro demais. O restante tem suas pequenas particularidades e pouca atenção dos programadores mais experientes e tradicionais (programadores mais “velhos” não se arriscam com modismos).

    Eu utilizo PHP com MySQL não exatamente por que combina bem, mas por que foi adotado pela maioria dos provedores e parece que este é o mercado (até quando?).

    Também utilizo Delphi com MySQL e gosto muito desta combinação, mas não acho que seja melhor que Firebird ou Oracle (este sem sombra de dúvidas!). A propósito não gosto do PostGresql mas ele costuma ser bem mais rápido em diversos tipos de consultas.

    Emfim, vale mesmo a experiência de cada um, pois há quem dirija um carro e que talvez não dirija bem o outro, embora as marchas sejam as mesmas. E é bom ver “cada caso um caso”.

    Responda

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.