O Firebird é derivado do código Borland InterBase. Quando efetuado a abertura de seu código na versão 6.0, mesmo distribuindo o código fonte do InterBase, a Borland anunciou a continuidade no desenvolvimento de versões comerciais do produto.
O fato de novas versões serem lançadas com código fonte fechado, trouxe desconforto no relacionamento entre a comunidade Firebird e a Borland. Após o lançamento do InterBase 6.5 e 7.0 (ambos comerciais).
Alguns programadores, em associação, assumiram o projeto de identificar e corrigir inúmeros defeitos da, até então, Interbase 6.0. E nesse contexto, surgiu o Firebird 1.0 em 25 de Julho de 2000. A versão mais recente estável é a 3.0, lançada dia 19/Abril/2016.
Aqui a linguagem SQL (Structured Query Language) é utilizada de maneira relativamente parecida entre os principais bancos de dados relacionais do mercado.
Por que Firebird é o querido?
Por ele ter nascido de códigos desenvolvidos da Borland. Muitos desenvolvedores utilizavam Interbase como uma versão acessível e conhecida para aplicações Delphi (linguagem da Borland na época).
Nesse contexto, foi fácil disseminá-lo entre os DEVs que utilizavam a mesma linguagem, ou seja, funcionou como uma ponte migrando para outras linguagens que possuíam o mesmo princípio visual.
Era real, existia um banco de dados de fácil instalação, configuração e com arquivo único, até mesmo, sem dispor de muita segurança. No início dos anos 2.000 havia uma ascensão do mercado ERP, vários conceitos estavam sendo aplicados, como: serverless, escalabilidades e metodologias. Mas será que havia espaço para o conceito cloud ?
A maior preocupação nesta fase, estava no visual, ou seja, com o recém-lançado Windows XP. As maiores Software Houses da época começaram em larga escala a conversão de seus sistemas integrados baseados em DOS (como Clipper e COBOL), que não trabalhavam com banco de dados relacional.
Naquele momento, a maioria trabalhava apenas arquivos de dados, ou seja, estavam prestes a perder mercado para Software Houses que já estavam nascendo com sistemas tão elegantes e de fácil operação, como o Windows XP.
Pontos para ficar de olho no Firebird
Um desenvolvedor cria um banco de dados (e, normalmente, um aplicativo cliente que o acompanha) para instalação em locais remotos. Nestes locais, é natural que ao menos uma pessoa da empresa tenha acesso irrestrito ao computador no qual o servidor Firebird será executado – para poder comandar tarefas como backup’s e manutenção. Ou seja, o acesso direto aos arquivos permite que se ganhe acesso completo e irrestrito a toda a informação das tabelas (dados e metadados).
Nestes casos, o desenvolvedor pode não confiar que os usuários deste local respeitarão a propriedade intelectual que este banco de dados representa. Então, fica o receio de que o usuário faça a engenharia reversa do banco de dados por interesse próprio, ou que não haja, neste local, uma preocupação real em manter seguros os arquivos a acesso de terceiros.
Contras do Firebird
Algo que o Firebird deixa a desejar, é o seu controle de acesso simples. O procedimento padrão para toda instalação, mostra que não há muita preocupação com esse ponto.
Além disso, o Firebird não oferece nenhuma facilidade integrada de encriptação. A resposta simples às questões de segurança é que isto não pode ser feito com as atuais capacidades do Firebird. Se um usuário tem acesso direto ao arquivo, também terá acesso irrestrito às informações dele.
Existe apenas uma solução possível para esses problemas: armazenar o banco de dados em seu próprio computador e usá-lo como servidor remoto. Dessa forma você permite que os clientes conectem-se ao banco através da internet. Terminal server (Windows ou Linux/Unix) é uma alternativa interessante para implementar esta estrutura.
Desta forma, você fica com o controle sobre o arquivo de banco de dados e pode restringir o acesso às suas informações, ou seja, começa aqui um problema de escalabilidade.
O modelo de servidor Embedded Firebird por ser muito leve e permitir ser executado em praticamente qualquer tipo de dispositivo
Servidor Firebird Embedded
Há uma versão especial do servidor Firebird chamada de “embedded”. Esta versão é, na verdade, uma biblioteca cliente especial, que inclui o servidor em si.
Quando um aplicativo chama essa biblioteca, ela carrega o servidor e permite acesso direto a qualquer banco de dados do computador local. Dessa forma, não usa o banco de dados de segurança.
O nome de usuário especificado durante o “logon” (não existe autenticação de senha) é utilizado para gerenciar o acesso aos objetos do banco de dados (por permissões SQL), mas se este usuário for SYSDBA (ou o dono do banco de dados), então, o acesso irrestrito é possível.
As características do servidor embedded são úteis a desenvolvedores que querem criar aplicativos monousuários simples de se distribuir e que não requerem muita segurança.
Dessa breve descrição, pode parecer que ter um aplicativo com servidor embedded instalado em um servidor que esteja armazenando outros bancos de dados possa representar um grave risco à segurança. Mas na realidade, o risco não seria maior se o servidor embedded não existisse.
Adaptando o modelo Firebird o mercado Atual
Transformando a aplicação como sendo o próprio servidor utilizado da sua configuração Embedded, neste ponto podemos trabalhar com um modelo de aplicação independente e offline, muito utilizado para rodar em Smartphones.
Perfeito para pequenas aplicações que não necessitam de uma alta disponibilidade e um número elevado de usuários, sendo uma excelente escolha para criar catálogos de demonstração de produtos, agendas ou pequenos utilitários.
O modelo de servidor Embedded por ser muito leve e permitir ser executado em praticamente qualquer tipo de dispositivo, minimiza os problemas de distribuição, escalabilidade, e configuração das pequenas aplicações, tornando-se a solução ideal para apresentações de software e pequenas aplicações.
Aplicações embarcadas está em crescimento relativamente alto, ainda mais com o preparo para o mobile, outro tema muito importante na comunidade. Desenvolver uma aplicação embarcada faz com que o seu software seja capaz de ser executado em qualquer tipo de dispositivo, dispensando a instalação, configuração, distribuição de arquivos e muitas outras etapas.
A princípio pode parecer complicado, afinal, imaginando esse cenário: o que, necessariamente, devemos mudar ou configurar em nossa aplicação para que seja possível gravar dados em dispositivos portáteis? A resposta para essa pergunta é, nada.
Toda a característica de Embedded, neste caso, concentra-se no servidor de banco de dados que suporta este recurso. Claro que para desenvolver aplicações embarcadas, poderíamos fazer a persistência dos dados em arquivos .txt ou .xml ou Json localmente.
Ou então, outro conceito mais utilizado para aplicações Mobile é o SQLite, e depois atualizado por API concentrado em um Banco Online com escalabilidade para concentrar todas as informações, com toda segurança exigida atualmente.
Mas estamos falando de um conceito ainda reutilizado desde os anos 2000, no qual foi aderido muito bem no cenário da época.
É possível ter escala e fácil usabilidade em bigdata com Firebird ?
Apesar de não ser o DB favorito para isso, e nem o mais fácil, para isso, sim é possível, mas se prepare para as dores de cabeça.
Seu funcionamento em 64 bit foi apenas liberado a partir da versão 3.0, e após isso que apenas estamos conseguindo medir sua performance, em ambientes desse porte, até então pouquíssimas empresas se aventuram em Big Datas, utilizando Firebird.
Seu sistema de segurança não é dos mais seguros, e seu sistema de integridade de dados menos ainda, é muito comum, trombarmos em rotina de empresas de alta performance, bancos que não tiveram seus commits encerrados adequadamente, quedas de energia, perda de índices corrompidos em sua estrutura de tabela, todos pontos simples na maioria da empresa, mas que derrubam a integridade de seu arquivo, o deixando corrompido.
Para restaurar um banco, Firebird, utilizamos um processo chamado de Backup / Restore, podendo eliminar campos corrompidos, desligando índices obrigatórios, para depois, eliminar os registros manualmente, e assim, recuperar todo seu conteúdo restante.
Mas não é um trabalho dos mais rápidos, já tive experiência de trabalhar com bancos de 10 gigas, no qual um processo de backup levou 1 hora! E depois o restore mais 1 hora, então agora vamos escalar 1h a cada 10g, e chegarmos a um banco de 100 gigas, como seria esta realidade?,
Se sua sensibilidade de corrompimento te coloca em uma prática relativa a este concerto no mínimo 1x por mês, será que ele ainda é viável para sua aplicação? Evitar a sensibilidade do Firebird, é mais dificil, porém trabalhar no tempo de resposta a sua reabilitação, pode ser o caminho.
O Firebird disponibiliza uma ferramenta pouco conhecida ainda entre os fãs deste DB, e ela pode ajudar muito na sua reputação, é o “Backup Incremental”, feita a partir do Backup, já vi exemplos publicados pela IBSurgeon (empresa Russa especializada em administração de Firebird), eles demonstram bancos facilmente gerenciáveis de 450 gigas, algo impensável com Firebird!
No caso, os backups incrementais são quebrados, por mês, semana, dia, hora, isso fragmenta seu banco de dados separadamente pela proporção de dados de cada intervalo, quebrando os tamanhos, ou seja se vc tiver um corrompimento, provavelmente será no intervalo de 1 hora que seria onde efetivamente o fluxo de atualização estaria constante.
Em um banco desse tamanho, apenas 1 hora de dados, recuperar e levantar isso proporcionalmente a 450 gigas, já se torna algo muito mais viável, talvez não para uma aplicação mobile, mas para uma aplicação server, com certeza.
