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

Sex Jun 27 15:01:43 -03 2008

É isso ai Eduardo... devemos caminhar de acordo com nossas necessidades. 
Para mim não existem coisas impossíveis até que se esgotem todas as 
possibilidades de resolução para o problema.
Para nossa empresa essa flexibilidade seria de extrema importancia, pois 
diminuiria e simplicaria muito a manutenção nos sistemas da nossa empresa.

----- Original Message ----- 
From: "Eduardo Bahiense" <eduardo em icontroller.com.br>
To: <lista em firebase.com.br>
Sent: Friday, June 27, 2008 1:16 PM
Subject: Re: [firebase-br] Aplicação Multi-Banco...

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
>
______________________________________________
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