Firebird: O Firebird mereceria muito mais atenção do que recebe. A meu ver, ele deveria ocupar o lugar que o mySQL ocupa, visto que é possui um suporte muito melhor ao padrão(92) do SQL. E sua instalação é muito mais simples que o mySQL, um dos principais argumentos de quem é fã dele (mySQL).

Entretanto, essa situação seria a algum tempo, o mySQL nessa ultima versão, parece finalmente estar se tornando um banco decente, e não só popular. E o Firebird está estagnado a algum tempo, além de ter uma documentação deficiente.

Firebird: O Firebird não está estagnado não, tanto que a versão 2.0 está em beta e trazendo várias melhorias. Também existe até um livro em português sobre ele

http://www.warmboot.com.br/fb/livro/fbessencial/

O maior "problema" que vejo é que por ele ter tido origem no Interbase da Borland, o seu maior diferencial é a facilidade de uso dele com o Delphi. A enquete abaixo demonstra claramente isso

http://www.firebase.com.br/fb/polls.php?resultado=13

Por isso mesmo, os principais usuários são programadores windows e o seu maior uso acaba sendo em servidores windows e como parte de sistemas feitos para windows. O próprio livro que citei acima não aborda a instalação em linux e inclusive eu msmo fiz uma crítica ao autor sobre isso, que prometeu melhorar isso na próxima edição. Mas isso tudo não significa que não possa ser usado no linux e com linguagens de programação livres.

O Firebird tem um site exclusivo de notícias e artigos

http://www.firebirdnews.org/

Há um site em português sobre ele

http://www.firebase.com.br/fb/


O Ingres é ainda menos conhecido (a não ser no meio acadêmico) e parece ser interessante. Vamos ver se surgem mais projetos de softwares livres que o utilizem e mais tutoriais e documentação na internet.

------------------------------
Em breve:

Comunidade de Usuários do Mandriva Linux no Brasil
http://mandrivabrasil.org

Firebird: O Firebird é um banco de dados extremamente poderoso, que eu uso e recomendo!

A empresa que trabalho tem aplicações desenvolvidas em MySQL, Postgres, e no Firebird. O firebird é extremamente poderoso e o utilizamos na aplicação principal da empresa. Apartir da versão 1.5.x a estabilidade e a confiabilidade ficaram muito boas, sendo que (quase) nunca tivemos problemas com esse banco de dados.

firebird e postgresql descend: firebird e postgresql descendem do ingres. isso é bem evidente no nome do post-gresql...

;; ((lambda (x) x) "Isto é um comentário e não será executado nunca")

Firebird: Eu aposto muito no Firebird. Minha empresa também. Sempre que posso, apresento o FB a amigos desenvolvedores e lhes dou dicas e até códigos prontos para que possam substituir, geralmente, o SQL Server em seus projetos.

Muita gente não usa banco livre por falta de conhecimento ou até por insegurança, ao pensar que o banco será difícil de instalar e administrar, ou mesmo que o desenvolvimento terá uma curva de aprendizado muito grande. Tenho 3 experiências bem sucedidas de amigos que migraram do SQL Server pro FB e estão muito felizes. Quando mostro a eles processos de instalação, admninistração e desenvolvimento, eles simplesmente ficam impressionados com a facilidade, performance e resultado.

Eu sou fã de carteirinha do Firebird, e todos os nossos projetos são baseados nele. Avaliamos MySql e PostGre na época, mas o FB ganhou de longe em cima de nosso cenário. Este é o ano do Firebird: a versão 2.0 está saindo do forno, e logo mais a versão 3.0 (q é resultado de um esforço paralelo ao desenvolvimento oficial, de nome Vulcan), estará na praça.

Indico a todos que conheçam o FB. Aos que gostam ou usam outros bancos livres, façam o mesmo. Muitos que já leram posts meus aqui mesmo no BR-Linux, sempre entram em contato e pedem informações. Fico contente em compartilhar conhecimento.

No caso do Ingres, não conheço. Gostaria de obter mais informações.

PostgreSQL não descende: Não, o PostgreSQL não descende o Ingres. E sim o criador do Ingres, Michael Stonebraker, resolveu criar um outro banco, Postgres.
Apesar do parentesco comum, os 2 projetos sempre seguiram rumos reparados, não compartilhando código.
Depois de ser abandonado pela Universidade de Berkley foi adotado pela comunidade, já que possuia licença BSD e ganhou novo nome Postgres95 e logo depois PostgreSQL.

Fonte: http://www.postgresql.org/docs/8.1/interactive/history.html

Firebird estagnado...: Talvez quando falei "estagnado" eu nao tenha me expressado bem.

Eu já notei no site que a versão 2.0 está sendo desenvolvida.

Entretanto, acho que eu deveria ter dito que o ciclo de desenvolvimento está muito demorado. Mas se for para ter grandes melhoras, ótimo.


Eu utilizo no meu dia-a-dia o firebird, verdade que não por escolha. Entretando o Firebird se encaixa perfeitamente no uso da empresa que trabalho, justamente por sua facilidade de instalação e praticamente dispensar adminitração.

Nesses quesitos ele é praticamente imbatível. Combinado a essa facilidade de instalação e conjunto de suporte ao SQL padrão MUITO superior ao mySQL. Por essas razões eu considero que deveria ser muito mais popular que o mySQL.

Quanto ao colega que o utiliza frequentemente nos seus projetos. Já vi problemas quando a taxa de acesso é alta e o arquivo fica muito grande, cerca de 500 M. Mas creio que isso será resolvido para o próximo release.

Mesmo com o mySQL tendo melhorado e muito, e finalmente ter se tornado um SGBD, pelo que mostrou no ultimo release... creio que o PostgreSQL está muito a frente de qualquer outro SGBD software livre.

Tem tudo que se espera de um banco de dados, porém não fica nisso, várias características avançadas.

Infelizmente todos os bancos livres, sofrem com o preconceito típico do software livre. Talvez até mais grave, visto que migrar um banco de dados não costuma ser simples, quando se tem toda uma estrutura montada sobre ele. E sistemas projetados para ter independencia de SGBD sao coisas relativamente recentes.

Sucesso do MySQL: O sucesso do MySQL é simples: ele sempre veio integrado ao PHP para fazer sistemas Web. E como o PHP fez um baita sucesso desde o começo, logo levou o MySQL junto pelas facilidades

:-)

Tenho um banco em FB com 2,5G: Tenho um banco em FB com 2,5G e ainda tá como no inicio.
Ja ajudei em varios trabalhos de consultoria clientes que tiveram problemas de performance e praticamente todos eles (com algumas excessoes) mantiam transacoes pendentes o dia inteiro. A tranquilidade de programação com Delphi faz com que muitos esqueçam da modelagem e tratamento das transacoes como por exemplo fazem o seu sistema ir com o dia inteiro numa unica transacao sem nunca fechar a nao ser quando se fecha o sistema. Alias transacoes sao um estorno para usuarios iniciantes que nao sabem porque seu registro é atualizado aqui e nao aparece atualizado acolá.

Na pratica fazem com o FB exatamente como se faria com Paradox, DBase, Access e esperam do FB o mesmo comportamento e não tira vantagens nenhuma do modelo Cliente/Servidor. Triggers, SPs, Functios,... ? Nao, eles nao querem.

"Mesmo com o mySQL tendo melh: "Mesmo com o mySQL tendo melhorado e muito, e finalmente ter se tornado um SGBD, pelo que mostrou no ultimo release.."

O que você considera que faltava ao MySql nas versões anteriores a 5.x que fazia com que ele não fosse considerado um SGBD?

Cássio R. Es_kelsen

Que chute para a lateral hein: Que chute para a lateral hein nemesis.

Uma comunidade adotou o Interbase 6 opensource desenvolvido pela Borland e deu um saveas com o nome FirebirdSQL. Inicialmente o mesmo código, depois com a versao 1.5 distanciou-se em recursos e muito codigo da borland foi extinto e para a versao 2 (em beta) muitas novas features serao acrescentadas. A demora da versao 2 é porque alguns recursos estarão aparecendo pela primeira vez no Firebird, e muitos dos que trabalham no códigos primam pela estabilidade.

Uma curiosidade interessante é que excelentes engenheiros da Borland vao pipocando em outras empresas, além da Microsoft, MySQL e Firebird contam com ex-engenheiros dela.

O que você considera que fal: O que você considera que faltava ao MySql nas versões anteriores a 5.x que fazia com que ele não fosse considerado um SGBD?

Chave estrangeira, Stored Procedures e Transações.

Nem vale mais a pena citar isso, pq parece q finalmente resolveram essas deficiências.

Dizer que essas coisas não são necessárias para a maioria das pessoas nao adianta. Muitas dessas pessoas tem seu primeiro contato com banco de dados com mySQL. Daí, como já presenciei, acham o máximo quando sabem que "podem rodar um programa no banco"(Stored Procedure).

Ou seja, tem contato com um banco deficiente, talvez se já tivessem esse recurso disponível, fossem utilizá-lo ao natural.

Bom, controle de transação: Bom, controle de transação já tinha a muito tempo (nativamente na versão 4.x e opcionalmente na 3.x)

Na definição "acadêmica" de SGDB, ter stored procedure em um banco não é requisito para que ele seja considerado um Sistema Gerenciador de Banco de Dados. Apesar de não ser "acadêmico", corroboro dessa idéia pois usar stored procedure é uma opção da pessoa.

Eu particularmente não gosto de Stored Procedures pois elas diminuem a legibilidade de um sistema, dificultam a manutenção, te amarram a um banco e aumentam a probabilidade de erros em sistemas com refactoring constante.

Cássio R. Es_kelsen

Tudo o que voce disse sobre S: Tudo o que voce disse sobre SP, multiplica por -1, porque é exatamente o contrário. Só não usa SP e outras features do lado server quem realmente não sabe tirar vantagens disso. Para quem conhece modelagem de sistema é uma mão na roda.

Quando o time do PHP ameaçou: Quando o time do PHP ameaçou desembutir o MySQL do PHP por causa da interpretação da licença do MySQL (realmente confusa), a MySQL AB rapidinho alterou a licença para satisfazer o PHP. Os time do MySQL não quer perder essa boquinha nunca, mas tambem : quem não faria o mesmo ?

Opinião sua... : Opinião sua...
Deixei bem claro que é opinião minha.

Ao contrário do que você insinua, conheço muito bem modelagem de sistemas. No entanto, a partir do momento que comecei a pensar quase 100% OO, as SP se tornaram um peso na modelagem.

Cássio R. Es_kelsen

reprisando o que eu disse :"S: reprisando o que eu disse :"Só não usa SP e outras features do lado server quem realmente não sabe tirar vantagens disso.".

Não estou atirando pedras em voce (embora pareça), mas é que voce precisa melhorar seu argumento. Algumas pessoas nao usam regras, procedimentos armazenados, functions, bla,bla no lado server porque quer manter seu produto multi-banco, ou regras estarao em camadas diferentes(n'tier), ou a modelagem não requereu, ou vai ser apenas um repositorio de dados e tantas outras razoes, mas porque sei programar OO é a primeira vez que ouvi falar.

Mas foi isso que falei desde: Mas foi isso que falei desde o começo:

"legibilidade de um sistema, dificultam a manutenção": n'tier, ou seja, as regras estão na BLL e colocá-las no banco duplicaria o trabalho poderia haver inconsistência entre as regrsa do banco e da BLL em caso de refactoring.

"te amarram a um banco": sistema multi-banco ;)

Cássio R. Es_kelsen