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

[Magno System]

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

Eduardo, agora eu concordo com você. O que eu quis dizer é que às vezes eu 
vejo tópicos, dizendo que a portabilidade depende só do componente. E 
realmente, você confirmou o que eu disse. Se quiser portabilidade, muitas 
vezes tem que abrir mão de recursos do banco.

EMPRESA: Marcelo Guimarães Nogueira
NOME FANTASIA: Magno System
ENDEREÇO: Rua Oliveira Leite, 66 - Centro - Passa Quatro - MG
EMAIL: magno em speet.com.br
CNPJ: 07.693.076/0001-99

Marcelo Guimarães Nogueira
Magno System (Empresa Desenvolvedora de Software)
----- Original Message ----- 
From: "Eduardo Bahiense" <eduardo em icontroller.com.br>
To: <lista em firebase.com.br>
Sent: Saturday, April 12, 2008 11:30 PM
Subject: Re: [firebase-br] Portabilidade!!!!!!!!!!!!!!!!!!!!


> 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


______________________________________________
FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
Para saber como gerenciar/excluir seu cadastro na lista, use: 
http://www.firebase.com.br/fb/artigo.php?id=1107
Para consultar mensagens antigas: http://firebase.com.br/pesquisa


-- 
Internal Virus Database is out-of-date.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.21.7/1329 - Release Date: 14/3/2008 
12:33