Banco de dados Firebird em aplicativos: o que é necessário?

Um software com banco de dados Firebird apresenta uma grande complexidade para ser transformado em aplicativo, exigindo o uso de diversos componentes.


Embora seja bastante usado entre as empresas de tecnologia e software houses, o Firebird é um banco de dados antigo e de difícil escalabilidade. Isso traz dificuldades na hora de criar um aplicativo mobile para ERP, dificultando o trabalho dos desenvolvedores.

Não que seja impossível realizar essa missão, mas são vários os desafios a serem superados. As equipes precisam aplicar grandes esforços, altos investimentos e custos, demanda de tempo e mão de obra especializada, entre outros.

O processo de criação desses aplicativos com banco de dados Firebird envolve questões específicas e alinhamento de linguagens. Há vários detalhes que precisam ser conhecidos com cuidado. Quer saber mais a respeito? Continue a leitura!

Saiba como levar o firebird para o mobile, clique aqui!

A história do Firebird

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.

Veja como o modelo firebird se comporta atualmente.

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.

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

Conheça o PlugMobile

Firebird para aplicativo com o PlugMobile

Com tantos componentes necessários para transformar o seu ERP em aplicativo com o banco de dados Firebird, nós da TecnoSpeed podemos te ajudar! O PlugMobile proporciona uma API pronta e preparada para cumprir essa missão.

Com acesso ao Firebird, ela expande a quantidade de conexões ativas em apenas uma integração. Basta conectar o seu banco de dados a partir de um arquivo .FDB.

Leve o seu software com banco de dados Firebird para o mobile com facilidade e praticidade. Conheça o PlugMobile e integre já!

Formado em Comunicação em Multimeios. Analista de Marketing da TecnoSpeed, focado em produção de conteúdos para mídias digitais.

Artigos relacionados