Firebird

Aversão 1.0 do Firebird, apesar das melhorias introduzidas, é completamente compatível com o InterBase 6. Versões posteriores, como a 1.5 e a 2.0, recentemente lançada como Release Candidate 3, já não guardam plena compatibilidade com aquela versão. Na versão 1.5, o código-fonte foi totalmente revisto e portado de C para C++. Além da mudança de linguagem, o Firebird ganhou novo gerenciamento de memória. Vale ressaltar que a versão 1.5 foi realizada nos bastidores do código, sem alteração na interface de programação (API), o que significa dizer que aplicativos escritos para a versão 1.0 funcionariam na versão 1.5 com pouca ou nenhuma alteração.

Em dezembro de 2003, com base no código alfa do Firebird 2, criou-se o projeto Vulcan com o propósito de redesenhar a arquitetura de threading do engine do banco. Com release previsto para 2007, o Firebird 3 (fusão do Firebird 2 com o Vulcan) promete ser a maior implementação no projeto do banco e está sendo desenvolvido para plataformas de 32 e 64 bits. Assegura-se que os programas escritos para as versões anteriores funcionarão sem mudanças nessa nova versão que, sem sombra de dúvida, apresentará uma estrutura muito mais robusta.

O Firebird (www.firebirdsql.org) é um software completamente aderente ao modelo cliente/servidor, especialmente projetado para uso local e redes WAN. Enquanto o servidor roda no computador hospedeiro da rede, a biblioteca cliente cuida para que a estação remota se comunique com os bancos de dados gerenciados pelo servidor. Por padrão, o servidor Firebird recebe (“escuta”) as solicitações dos clientes na porta 3050, que pode ser redefinida se julgado necessário. É importante detectar, no teste de uma instalação, se existe firewall bloqueando a porta padrão (ou a porta reconfigurada) e impedindo que as conexões se realizem.

Atualmente, o Firebird é distribuído em três formas: Super-Server, Classic e Embedded. A versão SuperServer trabalha com um processo único no servidor, criando linhas de execução (threads) para cada conexão. A versão Classic, indicada para ambientes com suporte SMP (Symmetric Multiprocessing), dispara um processo para cada conexão, necessitando de maior quantidade de memória RAM no servidor. A versão Embedded (embutida), uma variante do SuperServer para plataformas Windows, introduzida a partir do Firebird 1.5, é extremamente adequada para a criação de versões de demonstração de softwares, uma vez que o servidor, completamente funcional, é disponibilizado em uma única biblioteca dinâmica (fbembed.dll). Naturalmente, a versão é limitada ao método de acesso local e permite conexão com um único usuário. Uma aplicação “embutida” pode ser executada concorrentemente na mesma máquina em que se encontra um servidor Firebird normal. Contudo, os dois servidores não podem ter acesso a um banco de dados ao mesmo tempo.

Limitações de memória / storage / processador / plataforma

O Firebird, apesar da sua alta capacidade de armazenamento, é um SGBD extremamente leve. O processo do servidor do Firebird utiliza cerca de 2MB de memória. Cada conexão no modelo SuperServer adiciona aproximadamente 115K ao consumo de memória do servidor. No modelo Classic, cada conexão (processo independente), utiliza 2MB de memória.

Com relação à capacidade de armazenamento, assim como outras características de um banco de dados, há que se considerar os limites teóricos e os efetivamente obtidos na prática, principalmente pelas limitações do próprio sistema operacional. O tamanho máximo de um banco de dados Firebird, que pode suportar até 32767 tabelas, é de 7TB (7 terabytes). Na versão 1.5, por exemplo, cada tabela está limitada a 30GB (em torno de 2.000.000.000 de linhas). Esse limite desaparece na versão 2.0. O número teórico máximo de clientes conectados é de 1024 (protocolo TCP/IP), embora se deva trabalhar com um número máximo de 150 clientes concorrentes, no modelo SuperServer, em aplicações interativas consideradas “normais”. Entretanto, existem aplicações que suportam entre 300 e 350 usuários concorrentes, como as existentes na Livraria Municipal de Praga. Teoricamente, esse limite poderia chegar a 400 usuários, visto que as conexões do servidor estão definidas em processos de 32 bits. Um processo de 32 bits, como se sabe, não pode endereçar mais que 2GB de memória.

No Linux, os servidores SuperServer e Classic podem utilizar multiprocessadores com memória compartilhada. No Windows, todavia, o suporte SMP (Symmetric Multiprocessing) somente está disponível no modelo Classic. Projetado no final da década de 80, o modelo Classic permanece como a melhor opção para sistemas operacionais com capacidade limitada (ou inexistente) de threads ou para aplicações que necessitam de alto desempenho, desde que os recursos do sistema sejam adequados para lidar com o incremento de conexões, uma vez que cada conexão deriva um novo processo. Visto que os processos do servidor Classic podem utilizar múltiplas CPUs, esse modelo pode ser vantajoso para uma diversidade de aplicações críticas.

O servidor Firebird apresenta versões para as plataformas Windows, Linux e outras, como Sun Solaris (Intel e SPARC), FreeBSB, Mac OS X e HP-UX. Após a fusão com o Vulcan, o servidor estará apto a rodar em processadores de 64 bits.

Recursos de desenvolvimento (trigger, stored procedures, functions, XML, java e orientação a objetos)

Os recursos de desenvolvimento do Firebird são abundantes, incluindo triggers, stored procedures e funções definidas pelo usuário (user defined functions). Diversos drivers de conexão, pagos ou gratuitos, estão disponíveis para conexão com bancos de dados Firebird. Especialmente com relação a Java, os drivers JDBC JayBird, executados em Java 2 JRE 1.3.1, 1.4.x e 1.5.x, são distribuídos sem qualquer custo.

Os triggers podem ser executados em duas fases relativas à execução da alteração solicitada no estado dos dados: antes ou depois. Todos os gatilhos do Firebird são disparados em nível de linha, um a cada vez que a imagem da linha se altera. A versão 1.5 introduziu os chamados gatilhos universais, em que um gatilho pode estar associado a vários eventos. Para tanto, foram criadas as variáveis lógicas de contexto INSERTING, UPDATING e DELETING, que devem ser introduzidas e convenientemente tratadas no código do trigger. Com isso, é possível codificar um trigger como indicado na Listagem 1.

Listagem 1. Gatilhos universais.

...