Firebird , vale a pena ? o futuro da sua empresa pode estar amarrado a essa limitação.

[Fabiano Passianoto]

História

O Firebird é derivado do código do Borland InterBase quando efetuado 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 projecto de identificar e corrigir inúmeros defeitos dá então Interbase 6.0, surgindo aí 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

Baseado em SQL Structured Query Language, literalmente a linguagem padrão para realizar queries. A linguagem SQL é utilizada de maneira relativamente parecida entre os principais bancos de dados relacionais do mercado.

Porque Firebird ?

Por ele ter nascido por consequência de código desenvolvidos da Borland, e muitos desenvolvedores, utilizavam Interbase como uma versão acessível e conhecida para aplicações Delphi no qual era uma Linguagem da Borland na época.

Foi facilmente disseminado entre os desenvolvedores que utilizavam a mesma linguagem, e utilizando dessa ponte, migrando para outras linguagens, que utilizavam o mesmo princípio visual.

Um banco de dados de fácil configuração, fácil instalação e arquivo único, até mesmo sem dispor de muita segurança porém em um excelente time de mercado, em uma época onde se predominava, aplicações desktop, no início dos anos 2000, ascensão de um mercado ERP onde se desbravava vários conceitos como serverless, escalabilidades, metodologias, e o que se dizer de um conceito cloud ?

A maior preocupação nesta fase, estava na preocupação visual, recém lançado Windows XP, as maiores SofterHouses já existentes no mercado 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, a maioria apenas arquivos de dados, estavam prestes a perder mercado para SofterHouses que já estavam nascendo apresentando sistemas tão elegantes e de fácil operação como sua plataforma mais popular, Windows XP.

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 de lá tenha acesso irrestrito ao computador no qual o servidor Firebird será executado - para poder executar tarefas como backup’s e manutenção. Acesso direto aos arquivos permitem 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.

Algo que o Firebird deixa a desejar, seu controle de acesso é simples, e padrão para toda instalação, não existe ainda uma preocupação com seu controle de acesso.

E também 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 que tem acesso direto ao arquivo, tem acesso irrestrito às informações dele.

Existe apenas uma solução possível para esses problemas, na realidade: Armazenar o banco de dados em seu próprio computador e usá-lo como servidor remoto, para permitir que os clientes conectem 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, começa aqui um problema de escalabilidade.

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 acessível ao computador local. Dessa forma, não faz uso do 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 pode representar um grave risco à segurança. Na realidade o risco não é maior do que se o servidor embedded não existisse.

Uma adaptação do modelo Firebird para um mercado Atual

Transformando a aplicação como sendo o próprio servidor utilizando de 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 e 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 têm tido um crescimento relativamente alto, ainda mais com as questões de mobilidade que também estão em alta. 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 isto parece complicado, afinal imaginando esse cenário, nós já começamos a pensar 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 muito bem fazer a persistência dos dados em arquivos .txt ou .xml ou Json localmente um outro conceito muito 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 o qual aderiu muito bem o 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 64bit 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, por enquanto nada fora do normal.

Para restaurar um banco, Firebird, utilizamos um processo chamado de Backup / Restore, podendo eliminar campos corrompidos, desligando índices obrigatórios, e depois eliminando os registros manualmente, e recuperando todo seu conteúdo restante, mas não é um trabalho dos mais rápidos, já tive experiência de trabalhar com bancos de 10gigas, no qual um processo de backup levou 1hora, e depois o restore mais 1hora, então agora vamos escalar 1h a cada 10g, e chegarmos a um banco de 100gigas, como seria esta realidade?, se sua sensibilidade de corrompimento te coloca em uma prática relativa a este conserto no mínimo 1x por mês, será que ele ainda é viável para sua aplicação ?

Evitar a sensibilidade do Firebird, é mais difícil, 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 nBackup, já vi exemplos publicados pela IBSurgeon uma empressa Russa especializada em administração de Firebird, demonstrando bancos facilmente gerenciáveis de 450gigas algo impensável com Firebird, mas 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 tamanho, ou seja se vc tiver um corrompimento provavelmente será no intervalo de 1hora que seria onde efetivamente o fluxo de atualização estaria constante, e em um banco desse tamanho, apenas 1 hora de dados, recuperar e levantar isso proporcionalmente a 450gigas, já se torna algo muito mais viável, talvez não para uma aplicação mobile, mas para uma aplicação server, com certeza.

Por isso avalie bem, sua necessidade, o que precisa, e porque precisa, a longo prazo, quais os impactos vc causaria a sua aplicação, e a rotina do seu cliente ?