[firebase-br] Portabilidade!!!!!!!!!!!!!!!!!!!!

[Eduardo Bahiense]

> Portabilidade é uma das etapas que devem ser vistas na elaboração do
> projeto.
> Se a ideia e desenvolver um sistema que possa ter N base de dados o que é
> recomendado nos dias de hoje, sugirio o desenvolvimento em "N" camadas, onde
> a primeria seria a interface, a segunda o controle e acesso ao banco de
> dados e a terceira seria propriamente o banco de dados.


Então vamos pegar um gancho nas "n" camadas e multi-banco.

Temos hoje um produto "n" camadas onde a camada do meio (regras de 
negócio) recebe dados serializados em um padrão semelhante ao XML. Ela 
simplesmente não sabe nada nem de componentes de acesso nem de SGDB.
Neste projeto não usamos DBX, aliás, não sei qual a biblioteca de acesso 
utilizada, para se ter uma idéia de quanto isso intressa.

Planejamos a arquitetura para poder usar outro SGDB sem muito esforço, 
assim, resolvemos não abusar de Stored Procedures. Isolamos a criação e 
obtenção de generators em uma função centralizada e fizemos um 
repositório de queries que dão funcionalidade semelhante a Stored 
Procedures.

Inevitavelmente, por sermos "viciados" em FB, utilizamos com freqüência 
algumas sintaxes específicas do FB como SELECT FIRST SKIP.

Há algumas semanas participamos de uma concorrência que exigia Oracle 10G.

Extraímos o Metadata das tabelas e criamos o banco em Oracle com quase 
nenhuma dificuldade: Compatibilidade total dos tipos de campos, só 
tivemos que abrir mão dos DOMAINS, pois, ao que parece, o Oracle não 
comporta este conceito.

Fizemos uma análise das diferenças de sintaxes e teríamos apenas que 
reescrever as queries que utilizavam SELECT FIRST para o padrão do 
Oracle e isso poderia ser feito em poucos dias.

Como usamos um repositório isolado, copiamos o repositório renomendo-o 
para Oracle e fomos traduzindo as queries que exigiam adaptação ao Oracle.

Muitas das triggers utilizadas no banco, especialmente as de logs para 
auditoria são feitas por processos automáticos e também foi só adaptar o 
programa que as gerava automaticamente.

As poucas SPs que usamos também foram reescritas em Oracle.

No fim, foi só mudar o endereço do repositório na carga do sistema e 
pronto! rodamos em Oracle.

Claro, fizemos toda a arquitetura prevendo isso e quando aconteceu, nos 
beneficiamos deste planejamento.

Escolher o FB também fez parte do planejamento inicial deste projeto, 
pelo seu direcionamento ao padrão ANSI e isso se mostrou valioso nesta 
hora: Estrutura de JOINS, SELECT FOR SELECT, COALESCE, NULLIF, padrôes 
de delimitadores de campos e strings, tipos de campo, tudo portou direto 
pro Oracle.

O planejamento para ter facilidade de mudar de banco foi devido, como já 
disse antes, termos tido um custo elevadíssimo para sair do PIRADOX. 
Tivemos que reescrever o produto inteiro para SGDB. Nesta oportunidade, 
já nos preparamos para 3 camadas e agora, nesse novo produto, avançamos 
mais ainda.

É claro, para se conseguir isso, a equipe tem que ter muita disciplina, 
e, algumas vezes, abrir mão de um bom recurso do FB, ou pelo menos não 
abusar dele, para não ter que sofrer em uma eventual migração.

Então, o assunto PORTABILIDADE não envolve somente componentes de 
acesso, mas toda uma filosofia de desenvolvimento.

Portar sem esforço é utópico, mas se há previsão para isso, como já 
disse um colega, se pudermos tomar algumas atitudes que diminuam algum 
percentual do trabalho, já ajuda.

Parabéns ao FB e ao Oracle por manterem grande proximidade aos padrões 
ANSI e facilitarem nossas vidas.

Abs

Eduardo