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

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.


Publicado

em

por

Tags:

Comentários

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

  1. Avatar de carlsonwf
    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!!

    1. Avatar de Gnomo
      Gnomo

      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

    2. Avatar de Carlos H. Cantu

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

    3. Avatar de Juliano O. Barreto
      Juliano O. Barreto

      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.

    4. Avatar de Leonardo Freitag
      Leonardo Freitag

      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.

    5. Avatar de Marlon Pinheiro
      Marlon Pinheiro

      Por isso temos o data Warehouse…

    6. Avatar de Everton Sales
      Everton Sales

      Garanta um commit em toda alteração do usuario, assim ao faltar energia, etc, nenhum buffer será perdido… e a base sempre estará ok.

  2. Avatar de Dario
    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

  3. Avatar de Marcos
    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.

  4. Avatar de 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…

  5. Avatar de Marco
    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.

  6. Avatar de Felipe Jaekel
    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)

    1. Avatar de admin
      admin

      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.

    2. Avatar de Diego
      Diego

      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.

  7. Avatar de 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 é.

    1. Avatar de Fabio
      Fabio

      Ola

      Tenho preferencia pelo IbExpert, versão Free.

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

      []´s

      Fabio

  8. Avatar de Giovani
    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.

  9. Avatar de Luis
    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…

    1. Avatar de Sérgio
      Sérgio

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

      1. Avatar de admin
        admin

        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.

        1. Avatar de Sérgio
          Sérgio

          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.

  10. Avatar de Roberto
    Roberto

    Luis, já utilizei o Fibird com projeto em VB e não tive problemas, existe OLEDB pagos e free para conexão. A respeito de material verifique no site http://www.firebase.com.br/fb/, lá tem uma gama imensa de ferramenta para o banco de dados.

  11. Avatar de Sérgio
    Sérgio

    Ao autor,

    Caro autor, o link do MDB2FDB está quebrado.

    1. Avatar de admin
      admin

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

  12. Avatar de Frederico
    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.

    1. Avatar de admin
      admin

      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.

      1. Avatar de Frederico
        Frederico

        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.

  13. Avatar de Samuel
    Samuel

    Eu já utilizei o Firebird num projeto bem grande… e a perfomance dele é horrível!

  14. Avatar de Wagner Porto
    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.

  15. Avatar de Fernando Romulo
    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… :)

  16. Avatar de 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.

  17. Avatar de Felipe Cypriano
    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.

  18. Avatar de Ricardo
    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.

  19. Avatar de Jaider
    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.

  20. Avatar de Selmo Almeida
    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.

  21. Avatar de Gurgel
    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…

  22. Avatar de ncc_star
    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.

    1. Avatar de nmpvt
      nmpvt

      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.

  23. Avatar de carlos
    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

  24. Avatar de 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).

  25. Avatar de Diógenes Raizel
    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.

  26. Avatar de Costa
    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.

    1. Avatar de admin
      admin

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

  27. Avatar de Julio Cesar Develis
    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…

  28. Avatar de 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.

  29. Avatar de 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)

    1. Avatar de admin
      admin

      Eu também nunca vi uma base Firebird corrompida.

  30. Avatar de 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.

    1. Avatar de admin
      admin

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

  31. Avatar de 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.

  32. Avatar de joao
    joao

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

  33. Avatar de Ricardo Guilemond
    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”.

  34. Avatar de Alex
    Alex

    Eu trabalho desde 2002 com Firebird e nunca tive problemas com base de dados corrompida. Com certeza é o hardware que está causando esses problemas. Dos SGDBs gratuítos, o Firebird é o melhor.

  35. Avatar de João
    João

    Trabalhamos com firebird em mais de 130 bases espalhadas pela nossa região, e em 11 anos tivemos problemas em apenas 3 empresas, por problemas de hardware.
    E penso que, o fato de haverem bancos melhores, não significa que o firebird seja ruim. Na verdade é um banco super fácil de instalar, configurar, e manter. Além de ser super indicado para micro, pequenas e empresas de médio porte.

    1. Avatar de admin
      admin

      Oi João, compartilho da mesma opinião que a sua.

  36. Avatar de Edilmar Alves

    Eu trabalho com FB desde a época da dupla InterBase + Delphi da Borland em 1994, e já passei por todas as versões do FB. Atualmente uso FB também com Java e funciona muito bem. Uso apenas FB 2.5 e está muito bom, resolveu muitos problemas antigos que o FB tinha. Bases corrompidas no FB normalmente são culpa de hardware e não do software em si. Já tive problemas que consegui resolver com gfix/gbak, mas é fundamental ter uma politica 100% de backup dos dados, pois BDs de qualquer fornecedor estao sujeitos a serem corrompidos. Espero que o FB 3.0 resolva o problema definitivamente do dilema Classic x SuperServer.

    1. Avatar de tiago pereira
      tiago pereira

      agora sao 3: classic, superclassic e superserver. padrao selecionado é superserver

  37. Avatar de j2c9m7

    Firebird eh muito bom, ja tive banco com 10 milhoes de registros, e consultas super rapidas, tudo depende dos indices e de como sao formuladas as querys; 45 segundos e lento, e 100 mil registros numa consulta eh inviavel, acho que tem alguma coisa errada no seu sistema!

    1. Avatar de admin
      admin

      Fato. Já vi monstros rodando no Firebird também sem problemas.

  38. Avatar de junior

    alkem sabe me dizer se tem como recuperar base de dados imformix ibm…..eu estava fazendo atualizacao e corrompeu, aperguntae tenho como recuperar essa bando de dados corrompido….

  39. Avatar de junior

    fovro entra em contot por email unitecinfo@hotmail.com

  40. Avatar de Arthur Romano

    Trabalhamos com o Firebird a um tempo e nunca tivemos problemas de corrupção em banco de dados. Temos clientes com bancos com mais de 4gb e tabelas com mais de 18mihlões de registros que são acessadas instantaneamente. Para se ter uma idéia, temos clientes conectados on-line neste banco através de internet (aproximadamente 50 conexões remotas e em torno de 80 conexões locais) e mesmo com a comunicação sendo feita pela internet, nunca tivemos problemas de corrupção, sendo que a velocidade de acesso remoto é bastante aceitável. Firebird é 100% e não tenho do que reclamar.

  41. Avatar de Up Brasil

    Bem estive lendo alguns comentarios sobre o FB, bem sou desenvolvedor desde a versão 4 do delphi e em 99 comecei a utilizar o FB até hj tenho varios sistemas rodando com o FB e NUNK eu disse NUNK me deram nenhum tipo de problemas, recentemente visitei um cliente antigo a base dele ja esta com quase 8GB e rodando como se estivesse acabado de instalar.
    Hoje tenhu uma empresa de desenvolvimento de softwares utilizo JAVA e algumas vezes junto com FB, para mim JAVA+FB esta sendo exelente nada contra outros bancos como DB4O, MYSQL, POSTGREE etc… são exelentes bancos porem pela facilidade ainda continuo prefereindo o FB, e como ja disseram ai em cima cada caso eh um caso, eu particularmente recomendo FB 2.5 inclusive para se utilizar em desenvolvimento web com outras linguagens por ex o PHP…

  42. Avatar de Keferson

    Olá, bom dia! Aqui na empresa foi desenvolvido um software de lista telefônica que utiliza o Firebird. O que está acontecendo é quando vamos nos clientes instalar esse software, e se ele detecta que tem outro firebird na máquina do cliente, logo o nosso software não funciona. Há possibilidade de funcionar 2 firebird em uma máquina, alguma solução?
    Sei que aqui não é forum, mas vi que vocês entendem do assunto.

    Desde já grato.
    Saudações

    1. Avatar de Kico (Henrique Lobo Weissmann)
      Kico (Henrique Lobo Weissmann)

      Oi Keferson, provavelmente é só mudar a porta.

  43. Avatar de Keferson

    Boa tarde! Certo vou ver com o desenvolvedor. Obrigado Kico.

    1. Avatar de Kico (Henrique Lobo Weissmann)
      Kico (Henrique Lobo Weissmann)

      Flow! Precisando to ai!

  44. Avatar de Lairdevilson José Fiumane

    Pessoal, trabalho num empresa onde o banco é utilizado desde o Interbase hoje o Firebird, problemas de corrupções já ocorreram, mais por problemas de queda de energia, como alguns disseram acima, coloque um banco Oracle num servidor que muitos usam o Firebird e vejam também o resultado, dai façam o teste ao contraio coloque o Firebird num servidor onde se roda o Oracle e depois vocês venham falar.

    Aqui na empresa temos dezenas de clientes, temos banco com mais de 20 gigas e sem problemas, tudo depende de como foi montado seu banco, e as consultas que fazem, não adianta tem um banco Oracle seu o programador não souber programar.

    Trabalho com Firebird há anos e não tenho o que reclamar, e quem utilizam o IBEXPERT então está no céu.

    Como já ouvi antes e vou passar a diante, o melhor banco de dados é aquele que você sabe usar, não adianta tem uma Ferrari se você não souber liga-la.

    Não critiquem o Firebird se você não o conhecem, ele não é o melhor que o MS-SQL e o ORACLE, mais não perde nada para o PostgreSQL e o MySQL, cada um tem se valor.

    Quem critica o Firebird com certeza não sabe programar.

    Abraços..

    1. Avatar de Kico (Henrique Lobo Weissmann)
      Kico (Henrique Lobo Weissmann)

      Assino embaixo cada uma das suas palavras.

      Bacana a experiência: mais de 20 Gb com o Firebird? E como ele se comporta neste caso? Bem?

      Também sou fã deste SGBD :)

      1. Avatar de Lairdevilson José Fiumane

        Boa tarde!

        Olha tudo é relativo, claro que ficasse mais lento, mais um desempenho muito bom.
        Estamos desenvolvendo agora o log Externo para retirarmos os logs do banco principal.

        Aprovado Firebird com banco de 24,3 Gigas, com mais de 30 conexões.

        abraços…

        1. Avatar de Kico (Henrique Lobo Weissmann)
          Kico (Henrique Lobo Weissmann)

          Interessantíssima esta sua experiência, porque vai diretamente contra o argumento de que os bancos de dados Firebird são fácilmente corrompíveis.

          No caso, você fez um particionamento dos bancos de dados? Como foi a estratégia adotada? Ele simplesmente evoluiu pra chegar a este tamanho?

          1. Avatar de Lairdevilson José Fiumane

            Hoje está em apenas um banco, mais já começamos a migra para 2 bancos em alguns clientes.
            Apenas utilizamos o banco secundário para log, O log foi o maior causador do crescimento do banco, devido nosso sistema ter que ter os log de tudo que se faz o banco cresceu demais, agora como convertemos para o 2.5 estamos utilizando o comando “EXECUTE STATEMENT…..ON EXTERNAL” assim o banco mesmo controla os logs.

            qualquer duvida…

            abracos…

  45. Avatar de Carlos Daniel
    Carlos Daniel

    Trabalho com programação desde 1988, sou da época dos antigos banco de dados tipo “flat table”, passei pelo dBase, Paradox, Interbase 6 e hoje estou com o Firebird desde a versão 1.0 e posso dizer que em um universo de 300 cópias distribuidas tive 2 ou 3 problemas, que foram na verdade causados por falhas de HD no cliente.

    Também temos um sistema rodando em PHP com base de dados Firebird, em um servidor Windows com XAMPP, já roda a uns 2 meses sem qualquer incidente, embora deva confessar que é algo de nossa intranet e com baixo volume de acesso.

    Para quem usa o Firebird em aplicações criticas sabe que o rodar ele em um servidor Linux com RAID 0(espelhado) nem sequer afeta o desempenho. Um outro ponto que gostaria de destacar do Firebird é sua estabilidade em base de dados com armazenamento de arquivos binários, mais particularmente fotos no meu caso. Base de 3 GBytes sem qualquer sinal de problemas, rodando backup com os aplicativos cliente conectados e um fbserver.exe consumindo um máximo de 7% de processador… honestamente amigos, não vejo nenhum opção melhor, pelo menos entre os open source ou freeware que seja!!

    Abraços

    1. Avatar de Kico (Henrique Lobo Weissmann)
      Kico (Henrique Lobo Weissmann)

      Mais um belo exemplo de uso do Firebird. Valeu por compartilhar.

      É após ouvir casos como estes que fico intrigado com a pouca popularidade deste SGBD

  46. Avatar de Roberto Carlos

    Aqui na empresa utilizamos o Firebird desde a primeira versão, e desenvolvemos o ERP para gerenciamento de operadora de planos de saúde, (Saúde Online) em .NET e firebird, sendo que hoje temos quase 1000 usuários que acessam o sistema, fora os acessos via webservice que é feito por outras operadoras. O banco está com 10 GB e a perfórmance é fantástica, não trocaria o Firebird por nenhum outro banco de dados cidade, apesar de conhecer todos os outros.

  47. Avatar de Roberto Carlos

    versão, e desenvolvemos o ERP para gerenciamento de operadora de planos de saúde, (Saúde Online) em .NET e firebird, sendo que hoje temos quase 1000 usuários que acessam o sistema, fora os acessos via webservice que é feito por outras operadoras. O banco está com 10 GB e a performance é fantástica, não trocaria o Firebird por nenhum outro banco de dados citados, apesar de conhecer todos os outros.

  48. Avatar de Carlos Antônio Ferreira da Silva

    Temos cerca de 90 clientes espalhados
    na região do SUL de MG,
    todos com servidores simples,
    em sua maior parte sem nobreak até.

    As ÚNICAS VEZES que tivemos corrupções de
    banco de dados foi quando , no momento de um
    BKP/RESTORE, acaba a energia e está ou sem
    nobreak ou com nobreak desligado.

    Observação :
    Trabalhamos com automação comercial e industrial,
    desde fábricas de calçados, fábricas de produtos químicos,
    até farmácias, lojas de roupas, de materiais de construção,
    supermercados e outros…

    Uso praticamente todos recursos que o Firebird nos dá,
    estou usando atualmente a versão 2.1.3

    ABRAÇOS a todos… e quem ler a LISTA
    verá que o FIREBIRD é EXCELENTE
    e verá que quem REALMENTE O USA sabe do que ESTOU FALANDO,
    e não fica analisando “bebês da computação” que
    instalam o FB numa máquina velha , sem no break
    e querem que funcione como um ORACLE numa super máquina…
    Existe isto?????

    1. Avatar de Kico (Henrique Lobo Weissmann)
      Kico (Henrique Lobo Weissmann)

      Belos pontos.

  49. Avatar de Vinícius
    Vinícius

    O grande problema que encontrei no firebird são que quem criou o banco que eu usava não se atualizou e criou um banco muito ruim, em uma versão antiga do próprio firebird. O que torna a maioria das tecnologias ruims é quem as usa.

  50. Avatar de Meuzi Eduardo
    Meuzi Eduardo

    O Firebird é um caso de amor antigo. Impossível mudar.

    1. Avatar de Kico (Henrique Lobo Weissmann)
      Kico (Henrique Lobo Weissmann)

      Concordo :)

Deixe uma resposta

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.