P>
Clique aqui para ler todos os artigos desta edição
Firebird, essa é minha escolha, e a sua?
Saiba por que o Firebird pode ser a melhor escolha como SGBD para as suas aplicações
Carlos H. Cantu
É difícil imaginar uma aplicação comercial que não dependa de um banco de dados para funcionar. Independente do tamanho ou tipo, isso mostra a importância que os bancos de dados têm no mercado de software. Num passado não muito distante, a escolha de qual BD utilizar se resumia, além das questões técnicas, ao preço que se podia pagar pelas licenças. Felizmente, de um tempo para cá, tivemos uma verdadeira explosão de opções de bancos de dados gratuitos e open source.
Em uma primeira fase, o aparecimento e amadurecimento dos BDs Open Source e gratuitos mudou o cenário mundial, anteriormente dominado inteiramente pelos grandes fabricantes de SGBDs. Agora estamos vivendo a segunda fase do processo, onde os bancos de dados “frees” estão ganhando espaço na comunidade e no mercado, a ponto de alguns fabricantes estarem adotando a abertura do código de alguns de seus produtos, ou então revendo o custo das licenças ou o próprio esquema de licenciamento. Um exemplo real disso foi a abertura do código do InterBase (Borland), e mais recentemente do Open Ingres (Computer Associates).
Mas entre tantas opções “free”, qual é o melhor SGBD? A resposta para essa pergunta envolve a avaliação de diversos fatores, que variam de situação para situação. Mostrarei nesse artigo porque considero o Firebird uma ótima escolha, e porque resolvi adota-lo nos meus projetos que envolvem BD.
Um verdadeiro SGBDR
O Firebird já nasceu grande. Diferente de vários outros bancos de dados open source, onde muitas vezes não encontramos alguns recursos considerados essenciais em um SGBD relacional, o FB disponibiliza ao usuário todos os recursos de um verdadeiro SGBDR: Stored Procedures, Triggers, Integridade Referencial, SQL (em grande parte compatível com o padrão ANSI92/99), linguagem nativa (PSQL), UDFs (Funções Definidas pelo Usuário), etc.
Vale lembrar que a maioria desses recursos foram herdados do InterBase, portanto estão amplamente testados e tem sua eficiência comprovada.
Tamanho não é documento
Quem nunca teve contato com o Firebird com certeza levará um susto na primeira vez que for baixá-lo: a instalação do servidor tem cerca de 4MBs! Realmente o Firebird é um banco de dados muito leve no que diz respeito ao tamanho do servidor. No entanto, isso não atrapalha em nada a capacidade do banco em gerenciar projetos com grande volume de tráfego e informação.
Simplicidade
A instalação e manutenção de servidor Firebird é extremamente simples. O servidor não requer praticamente qualquer tipo de configuração manual (ver figura 1), dispensando na maioria das vezes a necessidade de um DBA. Para os que desejarem dar um “fine-tune” no servidor, o arquivo firebird.conf (ver figura 2) contém vários parâmetros que alteram algumas características do servidor. Esse arquivo normalmente não precisa ser configurado, pois as configurações padrões são geralmente suficientes para garantir a performance e operação ideal do servidor.
Os arquivos de BD (onde as informações são armazenadas) crescem dinamicamente conforme a necessidade. Não é necessário pré-alocar espaço baseado em deduções de nível de utilização e crescimento dos dados. Havendo espaço no HD, o Firebird o utilizará automaticamente.
Todos os objetos do banco (índices, procedures, triggers, etc.) ficam armazenados em um único arquivo, geralmente com a extensão .FDB. O tamanho desse arquivo, e conseqüentemente do banco de dados, está diretamente associado ao sistema operacional e sistema de arquivos utilizado (FAT, FAT32, NTFS, ext2, etc.). Caso o tamanho de um arquivo do BD alcance o limite permitido pelo S.O., pode-se facilmente dividi-lo em múltiplos arquivos. Essa divisão é transparente para o usuário. Tomando como base o uso do Firebird 1.5 e NTFS, podemos ter, em teoria, bases com alguns terabytes de informação.
Servidor Embedded
Disponível a partir da versão 1.5 do Firebird, o servidor embedded é a solução para alguns problemas que sempre acompanharam os desenvolvedores que utilizavam SGBDs relacionais. Com ele, temos um servidor Firebird completo disponibilizado em uma única DLL! É isso mesmo! Não é preciso instalar nada, basta distribuir sua aplicação juntamente com o embedded server e não será necessário alterar uma linha de código para que seu programa, que já funcionava com o servidor Firebird tradicional, funcione também com ele.
A única restrição é que apenas uma conexão por banco de dados é permitida (mono-usuário), tornando-o ideal para utilização em catálogos em CDROM ou distribuição de versões DEMO das suas aplicações.
Multi-plataforma
O Firebird está disponível de forma nativa para os seguintes sistemas operacionais: Windows, Linux, HPUX, MacOS, Solaris, SinixZ, FreeBSD, AIX e Darwin, WinCE (beta). Versões compatíveis com NPTL para o Linux com kernel 2.6 ou superior também estão disponíveis.
Versioning (MGA)
O Firebird utiliza o versioning, também chamado de MGA – Multi-Gerational Architecture - para o controle de concorrência no BD. Através do versioning, múltiplas versões de um mesmo registro podem estar disponíveis no servidor em um determinado momento. Através de um sistema otimista de concorrência, o Firebird permite que transações de leitura não bloqueiem a escrita ou leitura de outras transações. Estão disponíveis três modos de isolamento transacional:
· ReadCommited: A transação “enxerga” todos os dados já comitados por outras transações. Indicado para o uso em browses.
· Concurrency: A transação mantém a mesma visão dos dados (snapshot) de quando foi iniciada, permitindo manter uma visão consistente das informações. Inserções, alterações e remoções realizadas pelas outras transações concorrentes, não são refletidas enquanto a transação estiver aberta. Ideal para geração de relatórios.
· Consistency: Qualquer operação realizada em uma tabela por essa transação faz com que ela seja a “dona” da tabela, não permitindo que outras transações façam qualquer tipo de manipulação de dados na tabela. É um isolamento perigoso, pois pode provocar muitos deadlocks.
Enquanto que em outros bancos de dados o modo de snapshot (quando disponível) tem um alto custo para o servidor, no Firebird ele sempre existiu como padrão no versioning.
Opções de acesso
Existem inúmeras opções de acesso ao Firebird. Vejamos algumas delas:
· Nativo: acesso direto a API do banco. Geralmente é o modo mais eficaz. Exemplos de componentes que usam acesso nativo: IBO, FIBPlus, UIB, etc.
· JDBC: Jaybird (free e Open Source) – driver nativo Java tipo 4.
· ODBC: Existem inúmeros drivers ODBC para Firebird, alguns pagos, outros free.
