[firebase-br] Aplicação Multi-Banco...

[Eduardo Bahiense]

Olá

Este tópico é deveras interessante e merece uma análise cuidadosa.

Rodar Oracle e SQL server é uma demanda forte. São bancos com um apelo 
comercial muito forte e com grande reputação no mercado. Alguns 
pretensos clientes exigem que rodemos nesses bancos por já contarem com 
licenças e com DBA's na estrutura, além de precisarem integrar BI com 
informações de outros sistemas.

Além disso, em pesquisa recente na info-exame, a maioria esmagadora das 
empresas brasileiras de grande porte usam Oracle, SQL Server ou Postgrees.

Se formos optar por um banco único, dadas as características do nosso 
mercado, teríamos que ir pro Oracle 10G express, que atende 99% dos 
nossos clientes pequenos, é free e não tem qualquer resistência no 
mercado (os grandes já possuem licença de Oracle). Ainda assim, 
estaríamos descartando o pessoal que precisa do SQL server.

Quem está no mercado de pequenas empresas pode se dar ao luxo de nem 
falar em SGBD, isso não é relevante para elas (que bom que não tem custo 
adicional!). Para empresas médias e grandes, a coisa já complica, 
raramente aceitarão o FB se tiverem pessoal de TI especializado e/ou já 
tiverem estrutura montada para esses outros bancos.

O desenvolvimento multi-banco é possível e viável, mas o projeto tem que 
partir do "zero" com esse foco e tem que ser em camadas.

Basicamente, os seguintes processos precisam estar isolados:

1. Conexão com o banco

2. Recuperação de dados: É necessário usar um repositório que funcione 
como pseudo Stored Procedures, os aplicativos da camada cliente pedem 
result sets, sem saber que queries ou processos estão envolvidos em sua 
obtenção. Com este repositório isolado, fica fácil, no start up 
selecionar qual repositório utilizar, ORCALE, FB, SQL. Onde você usaria 
SELECT F1, F2, Fn FROM SP(P1, P2, Pn), você faria uma chamada a uma 
função GetPseudoSP_X(P1, P2, Pn) do servidor de aplicação.

3. Obtenção de PKs: deve haver uma função centralizadora para acomodar a 
diferença de sintaxe e lógica dos diversos BD. Os aplicativos da camada 
do meio solicitarão uma função do tipo PkId(<Nome da tabela>) e a camada 
servidora é quem saberá como obter.

4. Se houver opção por usar triggers para obter PKs, estas devem fazer 
só isso, pois essas triggers são tão repetitivas que pode se ter um 
programa gerador de suas ddl's facilmente.

5. Só quem deve saber qual banco se está usando e qual componente de 
acesso, é a camada de conexão com o banco.

Bem, dá para escrever 3 livros falando sobre isso, mas, basicamente, é 
isso, tem que partir do zero e abusar de isolamentos para se conseguir 
ser multi-banco, componente, plataforma e o que vier.

Abraço a todos


Eduardo


Artur Anjos escreveu:
> Na minha opinião, você perde mais do que ganha com essa opção.
> 
> Se as bases de dados fossem um mero "guardar registos" era simples, mas 
> não é o caso.
> 
> Você vai ter imensas soluções para acesso comum às várias bases de 
> dados, mas você vai perder com o facto de ter de desistir de usar as 
> potencialidades da base de dados.
> A mim, não me passa pela cabeça fazer uma aplicação em que não use 
> nenhum trigger, nenhuma stored procedure, etc.
> Não me passa pela cabeça sequer estar preocupado com a forma como a base 
> de dados controla as transações, se estas exisitrem.
> 
> Eu penso que nestas coisas não se deve agradar a gregos e troaianos: é 
> bem raro o cliente que se preocupa com a base de dados - interessa-lhe 
> mais a solução como um todo.
> 
> Artur Anjos
> http://www.serverptbr.com
> 
> 
> Custódio wrote:
>> Bom dia, 
>>
>> Alguem ja pensou, ou ja desenvolveu, alguma aplicação muito banco? Onde o mesmo sistema possa ser utilizado com diversos bancos de dados, sem nenhuma modificação no código fonte??
>>
>> Estamos iniciando o projeto de um sistema novo, e gostariamos de dar opções ao usuário de escolher qual banco de dados utilizar. Hoje existem versões gratuitas do oracle, mysql, sqlserver, firebird... isso nos permite flexibilidade de escolha para cada situação.
>>
>> Por exemplo... o firebird ou mysql são bancos de dados mais leves e mais fáceis de distribulir, e poderia ser uitlizado em lojas com até 2 maquinas. Agora o mesmo sistema, poderia ser utilizado por uma indústria, onde tenho 20 usuarios, onde comporta a utilização de um banco como oracle ou sql server...
>>
>> Algumas questões:
>> - Desenvolver rotinas SQL no padrão ANSI podem resultar em queda de desempenho, já que tenho que abrir mão de funções específicas de cada banco para poder ter compatibilidade.
>> - Alguem utiliza o UNIDAC, componente que permite utilizar vários banco de dados na mesma aplicação?
>> - Alguem possui algum caso de sucesso nesse assunto?
>>
>> Obrigado
>>
>>
>> ---
>> Carlos E. Custódio
>> custodio em gigatron.com.br
>> ---
>> GIGATRON Software e Treinamentos Ltda-ME
>> Rua Liberdade 1503 - Birigui (SP) - Fone (18) 3644-0043
>> www.gigatron.com.br
>> ______________________________________________
>> 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
>>
>>   
> 
> 
> ______________________________________________
> 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
>