Em determinadas aplicações utilizar recursos de software livre pode sair caro, abaixo um e-mail de uma empresa, cujo nome foi substituído por XPTO, relata a troca do banco de dados FireBird e suas respectivas razões.
Prezado cliente,
Alguns clientes XPTO que possuem o banco de dados FIREBIRD, estão enfrentando problemas devido às limitações deste banco, conforme relacionado a seguir:
- Não possui suporte;
- Limite no tamanho de databases;
- Grande incidência de corrompimento de bases;
- Recursos de administração do banco limitados;
- Problema de performance em grandes cargas no banco;
- Limitações tecnológicas do SGBD que causam problemas principalmente nos processos de criação e atualização de bases, e implementação de novas funcionalidades;
- Performance não atende os requisitos atuais do solução;
- Limitações para uso de multi-idiomas;
Por este motivo, a XPTO lança uma campanha de migração do banco de dados FIREBIRD para os bancos de dados POSTGREE SQL, ORACLE ou MS SQLSERVER.
Se a sua empresa possui os produtos XPTO rodando com o banco de dados FIREBIRD e deseja receber uma proposta de conversão de base de dados, por favor envie um email para emailoculto@xpto.com.
Li seu post 3 vezes e não pude deixar de ficar com a idéia de ‘WTF?!’ na cabeça.
Pô legal as outras companhias de BANCO de dados estão preocupadas com o FIREBIRD e já estão plantando falsas notícias, é só dar uma googlada e ver que isto tudo é mentira.
FIREBIRD FOREVER
O Firebird é bom para pequenas aplicações, quando o banco cresce ele deixa muito a desejar…
Como opção free eu prefiro o Postgres, que tem muitas funcionalidades e é bem robusto por ser free, até hoje não tive problemas com ele. Mas, se puder pagar, o SQLServer vale muito a pena, eu adoro.
Um abraço!
Já trabalhei com Firebird e hoje, infelizmente, trabalho com SQL Server. O Firebird é melhor em tudo, porém, precisa ser corretamente instalado e configurado, e em um servidor decente. Com certeza esses problemas citados são frutos da pura incompetência dos DBAs e desenvolvedores envolvidos. Post infeliz.
Bom… pelo o que podemos notar, programação é igual a futebol e religião… vc sempre vai defender o seu. Mas quando o assunto é solução de problemas dos clientes, todo o cenário deve ser analisado. Se a necessidade for quantidade de databases, replicações ou até quantidade de dados armazenados, sem sombra de dúvidas o SQL Server© é muito superior ao Firebird. Uma coisa que o Firebird tem de muito bom é sua ferramenta de gerenciamento, que possui tudo(tudo mesmo), o que vc precisa para configurar e trabalhar com seu banco.
Mas como eu citei acima, sempre vai ter quem discorde, e é por isso que temos uma gama de SGBD para que possamos avaliar e escolher o que melhor nos atende.
É como dizia minha vó “O que seria do azul se todo mundo gostasse de amarelo…”
Firebird em boas mãos e bem configurado supre muitas necessidades e não deixa a desejar em segurança. Falar que o Firebird não tem suporte soou muito estranho, eu não acho pouco a quantidade e qualidade do suporte dos membros da comunidade Firebird, porém, no entanto, se queres pagar pelo suporte, aceitamos também. Rs…
PostegreSQL é o que é mais próximo da perfeição, parrudo, veterano; e roda nas melhores plataformas deste universo; Só perde para Oracle, mas em caso de cluster[¹].
Uma coisa, “comprar” o melhor SGBD(OR) do planeta e não investir em DBA, você terá muitas dores de cabeça, para comprovar é só aguardar o tempo, quando teu banco tiver maduro e gordo.
MySQL (agora, MariaDB) => Só mais um banco para web.
SQL Server© => Only Window$; tô fora! ;D
[¹] http://pt.wikipedia.org/wiki/Cluster
Uso firebird faz uma década e nunca consegui corromper uma base, gostaria de saber como alguns DBAs (DBAs ?) conseguem isso.
Que post infeliz.
Testes feitos indicam:
Bem pessoal, em resumo…as diferenças são assustadoras:
Mysql – 1o. lugar…leva menos que um segundo para 1 ou 1000 registros.
Oracle – 2o. lugar…leva menos que 6 segundos para 1000 registros…porém quase 1 segundo para 1 registro
Firebird – 3o. lugar…leva menos que 0.5 segundo para 1 registro e quase 14 segundos para 1000 registros
Postgres – 4o. lugar…leva menos que 0.3 segundo para 1 registro e quase 31 segundos para 1000 registros
fonte: http://javafree.uol.com.br/topic-10357-Teste-de-Desempenho-mysql-oracle-firebird-15-postgres.html
Pessoalmente utilizo o firebird 2.1 sem problemas com sincronismo de dados num banco de apenas 3 gigas em ERP delphi. Já tive problemas de corrompimento em uma filial, e estou tendo problemas com lentidão de certas rotinas – contudo analistas já informaram solucionar o problema devido a uma falha de programação, o que deve melhorar a velocidade na próxima atualização.
Por mais filosófico que seja a paixão pelo software livre, para grandes empreendimentos certamente oracle ou mysql sem dúvidas.
Sucesso.
Vexe, para completar a disculção. Até 3 meses atráz eu era defensor ferrenho do FB, uso o 2.1, tenho uma pequena aplicação comercial, a 5 anos uso o FB sem nenhum problema, mas a 6 meses vivencio um problema, tenho dois clientes que ambos chegarão a casa dos 40MB de Tamanho de seus banco de dados. Até aí beleza, o FB continua atendendo os requizitos, porém estou com uma dor de cabeça… fazem 6 meses que um cliente, estava com poroblemas, tenho 60 clientes usando o mesmo sistema, mas neste cliente a base de dados alcançou os 40MB e começou a dar problema de corrupção do banco de dados. Todo o santo dia o banco de dados infla de seus 40MB para 90MB, 120MB, direto o cliente temq fazer um backup restore para voltar ao normal, pois ele começa a ficar lento e as vezes trava o micro todo, o FBSERVER.EXE começa a usar 100% de CPU, ja mudei para o classic server mesma coisa.
Levei o cliente no bico, por um tempo dizendo que era normal, aliás o processo Backup/Restore é rápido. Trocamos o servidor e continuou mesma coisa, aí ficou por isso mesmo, eu culpei o HardWare, pois em todos é o mesmo sistema e funciona 100%, até mês passado quando fui pego de surpresa por outro cliente que atingiu 40MB uma semana depois ele começou a apresentar o mesmo problema, virei o sistema pelo avesso para achar alguma GAFE, que poderia ocasionar o erro mas não encontrei NADA, Passei a gerenciar as Transações no próprio sistema, e NADA. Todo o dia estes dois clientes tem de fazer o BACKUP/Restore. Ja está causando mal estar entre Cliente/Fornecedor. Virei a Internet inteira procurando a solução e nada. Achei mais relatos de pessoas até com o 1.5 que tambem rodaram seus sistema por 3, 4, 5 anos e nunca apresentou problema, e do nada ele começou com o mesmo problema que o meu. Os entendidos que dão o suporte ao FB, dizem: ahhhh, faz um backup/restore que volta. Eu pergunto que tipo de solução é está? Não resolve o problema, apenas ameniza o problema. Infelizmente me decepcionei com o FireBird, vou tentar como ultimo recurso instalar o FB 2.5, quando sair, mas se não resolver vou ter que migrar a base de dados, chega a me dar arrepio só de pensar. Por hora até resolver meu problema, não recomendo para sistemas que possam usar um grande volume de dados. 40MB nem é grande, mas atingiu este tamanho no meu caso, ja era, é decretado o incomodo.
Abraços.
Se alguém tiver a solução, eu agradeço de coração, vai me poupar um trabalho lascado.
Duas perguntinhas:
Para quem defende: VOCÊ USA ELE COMO PRINCIPAL EM SUA APLICAÇÃO? QUANTO TEMPO? QUAL O TAMANHO DO BANCO?
Para quem Critica:
VOCÊ JA USOU??? QUAL O PROBLEMA QUE ENCONTROU??? AQUI ESTÁ RELATADO O MEU.
Abraços
Tópico totalmente ***SEM NOÇÃO***. Tanto o banco comentado aqui (Firebird), quanto, MySQL e PostGreSQL são excelentes SGDBs gratuitos q atendem com sobra quaisquer expectativas de grande a médio porte. Sugiro as pessoas que tiveram problemas com qualquer um destes, que primeiro estudem bem Modelagem de dados,limites do SGDB e do SO, segurança, e otimização de Queries, antes de postar esse tipo de comentário. É sempre mais fácil colocar a culpa no SGDB do que assumir uma deficiência técnica. A internet tá cheia de exemplos de Bases de Dados enormes com estes SGDBs com excente desempenho, sugiro que também pesquisem sobre o assunto.
ALmir sei que vai dizer que sou doido. mas te garanto o problema nao está no Firebird e sim na sua aplicação;
Apenas veja: SUA aplicação atinge 40 mb e da problema, vasculhe a net e procure sistemas prontos com bds e popule ou ja populado ou tente achar alguem que use firebird e verá que essa critica nao tem muito fundamento. Trabalhei em uma softhouse onde tinhamos dois sistemas um erp em sql server e sistemas de frente de loja em fb. problemas eram sempre proveniente de praticas de programação errada ou intervenção de usuario (no caso de corrompimento de bases; no mais tem base de dados com mais de 20 filiais e acima dos 6 gb (isso nao é megas é gigabyte) e aplicação executava brincando com a vantagem pr ousuario final de nao ter que desombolsar milhares de reais com licenças do bd.
Miha opiniao: sempre é mais facil botar a culpa no cachorro. rss
abraços.
Concordo com o comentário acima.
Tenho um sistema que roda em firebirdo com acesso a uma base de dados hoje com 2.2gb.
Quando a base chegou nos 2.0gb começou a ficar um pouco lento. A solução foi:
1-Fazer um backup restore (para reescrever os índices e limpar os dados dos registros ecluídos)
2-Trocar o servidor para uma máquina melhor.
Hoje roda normal…
Uso o firebird em mais de 200 clientes, alguns chegam a ter base de 30GB de tamanho e fazem consultas pesadas na web, o que posso dizer sobre o firebird é que ele vem melhorando a cada release que passa, quando migramos do 1.5 para o 2.1 a diferença em desempenho foi notável cerca de 40% com o mesmo hardware, e também caiu um pouco o fato de ficar rodando o gbak toda vez.
Uma coisa que posso dizer é o seguinte, na verdade na verdade muita gente confunde corrompimento da base de dados, com sujeira na base de dados, como indices, e tables temps que não apagam seus registros, então fazer um backup/restore a cada 15 dias é mais que recomendável não porque o banco ta corrompido mas sim porque ele vai acumulando sujeira e isso vai fazendo ficar um pouco lento. Um problema conhecido que existe no firebird 2.1.3 é que quando um usuário fecha com ctrl+alt+del uma transação corrente o sgdb mantem por dias essa conexão, causando alto uso de processador e memoria, o firebird eu digo que é um bom banco, mas você tem que conhece-lo muito bem, pois é cheio de armadilhas, usar linux como servidor é fundamental, saber aumentar os parametros de cache em disco para melhor leitura e gravação de i/o e usar todo recurso de hardware é fundamental, conhecer o firebird.conf de tráz pra frente para tunar o banco e conhecer sistemas de arquivos para saber qual tipo usar é fundamental. Por isso que muitos programadores fazem mal uso do firebird e diferente do MS=SQL que por padrão vem com uma configuração pronta, o firebird por default não é muito bem configurado, mas digo, bem configurado e com um bom linux customizado para o mesmo, e com o seu sistema bem programado você não terá dores de cabeças, e também sobre gbak/restore é igual MS-SQL que tem que reiniciar o servidor de tempos em tempos porque ele incha o famoso tempdb então faça um script que execute um backup/restore uma vez por mês que vai resolver o problema…
O firebird 2.5 promete várias correções, mas o melhor estar por vir no firebird 3 quando o super-classic server estiver maduro.
Do mais é um bom banco
Concordo com o “BOI”, o problema é que os programadores hoje em dia so sabem programar. Nao conhece SO e nem o proprio banco que trabalha. Ai como outros comentarios, é mais facil culpar o banco.
O Boi, falou com razão!!!!. Tenho aqui o meu Sistema de Controle de Ponto Rural. Está no tamanho de 4GB, já faz 4 anos. Uso o Firebird com a versão 2.1x., sem dor de cabeça e rodando tranquilo. Tenho uma rotina no sistema que faz backup/restore a cada 5 meses. Gosto muito do Firebird…
MySQL não tem (ou não tinha) um serie de requisitos de um banco de dados relacional.
Uso do Firebird, muitos ignoram uma instalação e configuração correta bem como a instalação de um servidor de dados.
A corrupção dos dados esta ligado a problemas além de quedas de energia a copia da base, questão de segurança, pasta da base compartilhada e outros detalhes parecidos.
O Firebird 2.5, em versão de teste final, é muito rápida, muito bem mais que a 2.1.
Possuo bases de vários clientes, alguns passandos dos 4GB. Corrupção a todo momento ocorre, e todos eles são problemas de usuários.
Lentidão ocorre, algumas vezes por problemas do sistema:
– SQL mal montadas
– Modelagem
– Driver de acesso
mas na maioria esta na estrutura do usuário
– Servidor compartilhado com outras aplicações.
– Rede
– Disco do servidor lento ou fragmentado.
– Falta de manutenção (backup e restore períodico).
Almir entra em contato comigo que eu o ajudo a resolver o problema, também já passei por isso.
Pode ter certeza de uma coisa, o problema é quem administra o banco ou quem constrói a aplicação, independente se o banco é x ou y …
cezar.atl@ig.com.br
Pessoal, peço desculpa a todos, não estava mais acompanhando a matéria.
Sobre meu problema de estouro do banco, erros sumiço de DADOS. Etc. Falha de conexão Todo dia ter que fazer um backup/Restore só tenho uma coisa para dizer a todos, humilde-mente.
VAI TOMA NO C… FOI TUDO CULPA MINHA MESMO, pessoas com preguiça como eu estava que as vezes difamam um bom trabalho..!!.
Detalhe, falta de atenção associada a uma preguiça de revirar os fontes, fiz um monte de rotinas, passei a controlar minhas próprias transações, ou seja em todas as rotinas que repassei, melhorei todo o código ficou muito bom, e mesmo assim ainda aconteciam os mesmos erros, não cheguei a perder nenhum cliente, mas depois que escrevi o tópico acima, sentei e fui ler a documentação do POSTGRE.
Perdi o contato e não consegui achar mais o site, para ler os comentários e dizer que ja havia resolvido o problema.
Seguinte, ja havia feito o conversor de dados, e lendo a documentação do POSTGRE, me deparei com um tópico chamado “TRIGGER RECURSIVAS”. Na hora saquei o que havia de errado, nem terminei de ler, e entrei no banco, PQP descobri um monte de erros de lógica, só fui adicionando TRIGGERS nunca fiz uma faxina no banco de dados, e repassei todas minhas TRIGGERS refazendo-as e e 30 minutos depois testei, atualizei no cliente e nunca mais deu problema. FALHA MINHA, não é inexperiência e sim preguiça e falta de atenção.
Uma TRIGGERS disparava outra que disparava outra que disparava a mesma e ficava naquele loop infernal, até o servidor não aguentar e reiniciar o banco de dados, o banco de dados dos clientes almentaram no maximo 3mb desde aquela época.
Abraços
Boa tarde a todos.
Utilizo o Firebird desde que ele ainda era Interbase 6. Tenho clientes com base de dados que vão desde 100mb até 5gb E odas funcionam perfeitamente. O único caso que tive esses anos todos de base corrompida, era problema de hardware que detonava o banco de dados. O MySQL até pouco tempo atrás nao dava suporte a transações, por isso era tão rápido. Agora nas versões atuais, a performance se equivale ao FireBird. A questão do inchaço do banco, é questão de programação. Os malditos CommitRetaing e RollbackRetaining que gravam os dados e mantêm a transação aberta. Utilizo sempre Commit e Rollback normal e não tenho problemas de inchaço bas base de dados. Também não é aconselhavem utilizar tabelas temporarias em bancos de dados, porque uma vez que um registro foi alocado, o espaço dele fica lá mesmo depois de excluido, causando também inchaço do banco. Enfim, não troco o FireBird pelo MySQL de jeito nenhum. Acho que Firebird, Postgree, DB2estão em patamar um pouco mais alto pelo enorme volume de dados que eles gerenciam ( bancos de TB de tamanho ) Mas par aplicações de pequeno e médio porte, acho o Firebird simplesmente perfeito. Sem falar que ele e´de fácil instalação e manutenção.
sds,
Utilizei o firebird durante 4 anos no meu antigo emprego, tinha bases de até 2 GB utilizando o firebird 2.1…. Em questão de velocidade nunca deixou a desejar, muito rápido, muitas consultas complexas eram realizadas e a performace era incrivel.
Me encomodei realmente somente três vezes.
1º. O servidor(fbserver.exe) começava a ocupar muita memória e muito processamento, até que o mesmo caia e o cliente ligava pra encomodar. Reinstalando como superver deu uma tapeada mas não resolveu. Até que descobri o problema, culpa minha ;P, uma função mal programa em uma UDF não liberava direito as coisas da memória e fazia essa cagada.
2º Na versao 2.1.não_lembro_qual, ao usar a função agregada LIST, em uma consulta fodastica cheia das sub-querys a memória do servidor tambem começava a subir sem parar estourando depois de um tempo…
O problema eu resolvi com
*Iniciando uma transação
*Fazendo a consulta
*Rolbackando a transação
com isso a memória do servidor mateve-se estável. Acredito que isso foi realmente um bug do firebird, mas que em várias utilizações do comando LIST somente naquele SQL, nos outros era normal.
3º As vezes dava uma loucura que inseria uma chave primária com valor nulo… dava uma raiva… mas depois que mudamos pro firebird 2.1 foi rara as vezes que deu algo assim… no máximo 3 vezes
——————————————————-
Hoje trabalho em outra empresa com PostgreSQL e acho uma bosta, não vi nenhum motivo pra preferir ele ao firebrid…
Consultas simples são lentas, fazer sub-query muitas vezes é mais rápido que fazer “join”….. preciso de uma bola de cristal na hora de montar um SQL no postgres, algo que eu sei q no firebird seria rápido ao fazer no postgres demora……
Sem falar que a dependência dos objetos é muito fraca, não há como você saber onde determinado campo está sendo utilizado com 100% de certeza (ao menos eu desconheço)
Utilizamos o firebird 2.1 e 2.5 tanto em sistemas em rede quanto em sistemas com banco de dados standAlone e não temos queixas quanto a isso.
Temos banco de dados de clientes com 3 anos de uso, banco com mais ou menos 10MBs…
Unica queixa que tenho com o firebird é na restauração de bases de dados.. as vezes demora mais que o esperado, porém, funciona 100%.
Detalhe muito importante!
Não interessa qual SGBD você esteja utilizando… Um banco de dados relacional mal projetado(e consequentimente sujeito a vários updates e upgrades de tabelas e relacionamentos) refletirá concerteza no desempenho de sua aplicação. Seja ela qual for.
Unico problema que vejo no Firebird e a conexao remota, devido ao TCP/IP ser lento, mas tem Empresas de nome no exterior que tem bases de 1 Gb e nao da problemas(ver no site http://www.firebase.com( Empresas que usam grandes bases dados)).
Quanto MySql, nao sei se tem mesmo problema de conexao remota, mas tambem logo deve ter problema de licença gratuita.
Boa dia a todos, espero ajudar com minha humilde experiência de 13 anos com o Firebird
tenho clientes de pequeno, médio e grande porte, não tenho nada a reclamar sobre o Banco, é excepcional, seguro e rápido, as menores bases rodam em torno de 300 Mb a 1 Gb, médias de 2 a 5 Gb e grandes de 10 a 40 Gb, com 300 conexôes simultâneas entre Redes locais e Terminal Server, em uma aplicação em Delphi orientada a objeto, o segredo está no dimensionamento da aplicação, imprescindível controle transacional, controle de intervalo do sweep do BD, índices e Foreign Key, triggers e componentes adequados ao FB, ou seja, uma modelagem bem feita é tudo, uma dica que nos auxiliou muito, foi de sempre participar dos Tech Day Firebird em Piracicaba todo o ano com excelentes profissionais e experts do ramo, durante todo este período de experiência, só tenho a agradecer a equipe que desenvolveu e ajuda no desempenho deste ótimo BD,
não troco por nada, hj estamos colocando em um cliente dois servidores HP de 20 Gb de memória cada HD SAS, e processadores de 8 núcleos para trabalhar em Cluster rodando o Firebird 2.5 para atender a demanda de 300 conexões tranquilamente entre aplicações em Delphi e Web, vai a dica pesquisem bastante sobre o banco, consulte pessoas esperientes, reveja sua aplicação e modelem o BD com todo carinho, revejam Joins e indices que deixam lentos, uma aplicação lenta hj, vc tem inúmeras formas no FB de otimizá-la, um peq. ex ontem disponibilizei um relatório em Fast Report de 600 páginas de posicionamento de estoque de equipamentos com números de série que tem cruzamento de várias tabelas, algumas com mais de um milhão de registros, trazendo resultado do posicionamento de 50.000 números de séries em menos de 2 minutos.
O Banco é muito bom, não falem mal sem conhecer profundamente a ferramenta. Abraço a Todos
Post de grande infelicidade do autor, realmente coisa de quem não utiliza o FB. Posts assim, sem o autor entender do assunto que está publicando, diminuem a credibilidade do site.
Tenho experiência com o FB há mais de 10 anos e, EXCETO por problemas de hardware do servidor de clientes, NUNCA tive problema de corrupção de banco de dados.
Em minha opinião, uma das principais vantagens do FB se refere a sua excelente performance, inclusive com grande volume de dados e grande banco de dados.
Possuo atualmente mais de 1.200 clientes utilizando nossos sistemas, exclusivamente com FB (versões 1.5 e 2.1, e alguns poucos ainda com a versão 2.5).
Só tenho elogios e agradecimentos ao excelente trabalho realizado pelos desenvolvedores do FB, inclusive pelas constantes melhorias implantadas nas novas versões.
Grande abraço a todos.
Utilizo Oracle desde 2002 e só tive problema em 2 clientes rodando windows 2003 server com Oracle 11g em que o problema foi “ORA-01033: ORACLE initialization or shutdown in progress” por falha do windows.
Nunca tive problema com os citados ao firebird, sobre indices, lentidão, uso excessivo de hardware, seja cache ou ram.
É claro que o Oracle tem uma demora ao carregar, digo isso porque tenho instalado no meu notebook. Mas depois de carregado trabalha normal. Obviamente, em uso nas empresas, o servidor está sempre ligado e isso nem se nota. E também em servidores com Dell, Hp, isso não ocorre.
Bom, deixando de lado o Oracle que é licenciado e bem caro, quando li a frase “o barato sai caro” fiquei apreensivo pois estava justamente garimpando pela net para ver opiniões de profissionais que ja utilizavam firebird.
Mas ao mesmo tempo me tranquilizei porque a maioria que usa base de dados com volume considerável fala bem do firebird.
Não tenho nenhuma experiência com firebird, mas pelo que os amigos disseram acima, e pelo que se lê, na revista active delphi, o firebird vai muito bem.
Pretendo migrar para firebird porque é free e suporta base de dados da pequena a grande empresa.
Não sei se esse forum é para isso, mas posso pedir informações, tirar dúvidas sobre firebird, aqui?
Abraço a todos.
Descobri no firebird, uma excelente ferramenta no quisito BD. Trabalho com bancos que já te + de 4 GB e tem se mostrado consistente. Posso dizer que o post inicial, além de infeliz mostra que tem muita gente mau informada e acha que é o “dono da cocada preta”. Lamentável.
Boa noite a todos!
Eu utilizava interbase até o firebird surgir e melhorar em tudo. Concordo e discordo com alguns comentários a cima, mas eu confio mesmo é na minha experiência. O firebird é um ótimo SGDB e lhe dará um show de recursos se for bem configurado. Mas o mais importante, é a estrutura do seu banco de dados, dos bom relacionamento definidos, principalmente este último. Já me empenhei com alguns bancos que cresciam aceleradamente e outros que corrompiam com frequência. O segredo todo está nos relacionamentos interno do seu banco. Conheço vários outros programadores, assim como eu, que utilizam a mesma versão do firebird, mas que sempre se deparavam com problemas. Foi aí que percebi que a grande diferença dos bancos estavam no relacionamento. Os bancos problemáticos usavam tabelas soltas utilizando apenas índices independentes (péssimo isso). Foquem na estrutura, e vcs não terão problemas. Espero ter ajudado de alguma forma!
Não digo que esse é melhor que aquele… etc.
Entretanto foi mostrado na Softool’06, o “Avarda (ERP russo) que na época utilizava um servidor Firebird 2.0 Classic e com um número médio de 100 conexões simultâneas, atendendo a uma base de dados de 120GB com 700 milhões de registos.
O servidor era uma máquina bi-processada (2 CPUs – Dell PowerEdge 2950) com 6GB de RAM”.
Esse Firebird não deve ser fraco não…
Por favor qual a melhor forma de conexão delphi 7 com Firebird, estou migrando meu sistema em clipper. Se puderem ajudar agradeço.
Desde já obrigado.
Adriano
dbexpress do Delphi 7, seria a melhor conexão com o Firebird?
Acho que para falar de um produto ainda mais gratuito as pessoas(DBAs) antes de mais nada devem conhecer a ferramenta e não ser um mero usuário.
Muita informação inútil e poucos que conhecem realmente a ferramenta.
Lamento pela Gama que temos de profissionais da área e grande parte estão perdidos no que fazem.
Voltem aos livros e laboratórios aqueles que se sentirem mal com esse comentário.
Abraço senhores.
Firebird é um banco excelente.
Tenho mais de 20 anos de trabalho como desenvolvedor de sistemas……e aprendi uma coisa.
Sempre que fazem comentários demolidores e fantásticos, sobre um produto que é usado e aprovado por milhões mundo afora.
Ou é ma-fé ou deficiência técnica de quem faz.
Boa noite, temos clientes que o FDB já ultrapassou os 10 GB a mtoooo tempo, trabalhamos com FB 2.5 e até então não apresentou nenhum problema, já geramos fdb com 100 GB para testes de performance, e se comportaram perfeitamente bem, o detalhe esta na escolha da versão certa do FB, pois entre a SS,CS e SC tem muita diferença. abraço
Utilizamos aqui na empresa Firebird 2.1 em mais de 600 clientes. Temos bancos em torno de 10 gb. Trabalhamos com redes de lojas com replicação de dados.
Tínhamos problemas de corromper banco no início em que não era pré requisito Windows Server e hardware de qualidade. Hoje em dia temos pouquissimos problemas.
A grande chave em usar o firebird é montar um servidor bom. Configurá-lo é muito simples.
Problemas relatados a lentidão aí com certeza a pessoa terá problema com qualquer banco pois é uma questão de aprendizado(modelagem, desenvolvimento, etc) e não do BD em si.
Att.
Administro uma rede de uma loja de moveis, são 25 lojas cada loja com 10 a 15 maquinas deposito com 42 maquinas, rodando com firebird 2.5 online atraves de Vpn nosso banco esta com 4gb, é uma maravilha rapido muito bom. Firebird e otimo. O banco de dados precisa de uma boa rede, um bom servidor e configurações Corretas.
Vocês estão falando de 40 MB…. no máximo 2 GB….
Só podem estar de brincadeira, tenho duas bases de dados em SQL Server, uma de 42 GB e outra de 178 GB (isso mesmo), e nem sonho em rodar isso num programa gratuito sem suporte.
No máximo migrar pra Oracle.
Ao nasser, seu comentario é de quem não sabe nada do firebird e nem sequer leu esse post.
Nesse post alguns usuários mostraram esperiências com banco de 100GB e 120GB. mais esse não é o limite do firebird já foi realizados testes com bancos Firebird com mais de 1TB.
Não critique sem saber do que vai criticar.
Um abraço a todos
Tenho um sistema em várias empresas, há mais de 4 anos, com o sgdb firebird e o tamanho médio é de 2GB. A performance é excelente (custo/benefício) e os poucos problemas de corromper banco eram solucionados com um bom no-break ou troca de HD. Vale citar que trabalho, também, como administrador de dados com Oracle e SQL Server. Além das observações citadas anteriormente relacionadas às configurações, devemos ter cuidado com a montagem/alteração nas tabelas relacionadas às restrições.
Só para finalizar, o banco do meu sistema é transacional e em alguns pontos do sistema ele é consumido como DW (Business Intelligence).