Fórum Meu programa é multi-banco, o seu também? Pesquisa. #292242

18/08/2005

0

Delphi

Galera, gostaria de abrir um tópico aqui para discutirmos os programas multi-banco. Trabalhei com um software que podia ser utilizado com Oracle, Interbase e SQLServer usando o DBExpress, funciona muito bem.

Gostaria de saber se alguém já trabalhou com esse conceito e o que achou.

Para iniciar vou falar da minha experiência:

Este software podia ser configurado na tela de abertura, onde o usuário digitava sua senha e escolhia qual banco de dados queria trabalhar.

[color=red:0111ff60cd]Obs.: Somente os programadores tinham acesso a isso, pois no cliente configurávamos somente o banco de dados que o usuário tinha direito.[/color:0111ff60cd]

[b:0111ff60cd]O ponto positivo:[/b:0111ff60cd] Com certeza a possibilidade de você vender o sistema com banco de dados gratuito (Interbase) para clientes com pouca bala na agulha. Para clientes de médio porte (SQLServer) e para clientes com um grande poder de fogo (Oracle).

[b:0111ff60cd]Ponto negativo:[/b:0111ff60cd] quando você desenvolve alguma coisa que necessite de um comando especial em SQL por exemplo, é necessário testar em todos os bancos, ou seja, dá um pouquinho mais de trabalho você deixar o sistema 100¬ pq precisa ter um nível de atenção muito maior.

Bom, é isso...mandem ver.


Adriano Santos

Adriano Santos

Responder

Posts

19/08/2005

Lucianobarreto

Eu já fiz um programa de testes dessa forma onde eu acessava bases IB e MySQL. Eu achei interessante pelo fato de conseguir mudar em tempo de execução o banco de dados. Eu achei legal, mas como o Adriano Santos disse existem problemas com relação ao SQL, mas nada que os testes não resolvam!!!!


Responder

Gostei + 0

19/08/2005

Idivaldo.mb

Estou desenvolvendo um sistemas Mult-Banco e Tambem Multi-Empresa, tá dando trabalhao pra caramba, em minha opnião não sugiro ninguem a fazer isso, como os amigos á cima disseram é uma boa para você poder vender seu peixe, dependendo do seu cliente voce pode fazer uma proposta que lhe melhor agrada ao seu cliente, a unico problrma em desenvolver em multi-banco é que você tera que testar todos os bancos . Mas é um grande desavio á qualquer programador desenvolver isso tipo de sistema , nao pela complicidade , mas pelo trabalho e geracao de erros que o ocorre , que voce sempre tem que encontrar um caminho.

Ate mais


Responder

Gostei + 0

19/08/2005

Marcio.theis

Na empresa onde trabalho temos um sistema que trabalha em multi-banco, são 5 SGBD diferentes que ele é capas de acessar... e ainda é multi-empresa, na minha opinião é extremamente válido isto, pois você da ao seu cliente mais opções a ele, ou seja, deixa como ele se deseja ou não em investir em um banco pago ou deseja um free.... Na questão de multi-empresa é claro que se deve de ter um cuidado maior, visto que as empresas tem regras de negócios particulares... mas resolvemos isto de forma fácil criando um local de ´Parâmetros da Empresa´, ou seja, lá se configura de tudo, desde o banco de dados que vai acessar até se quer avisos no desktop do programa.
Este programa usa ADO, usando a forma de configuração de acesso ao SGBD através de UDL(na minha opinião uma das melhores coisas que já surgiram). Bem... o que quero deixar como recado é que na minha visão vale a pena e muito em ter um programa multi-banco e multi-empresa, o que é mais valido antes é efetuar uma ótima análise do sistema, projeta-lo, construí-lo e depois partir para o desenvolvimento... se os pontos básicos iniciais não estiverem bem definidos... depois será muito difícil trabalhar com multi-banco ou multi-empresa.


Responder

Gostei + 0

19/08/2005

Motta

Uma solução e ter uma camada de acesso , não é simples , nem fácil , mas depois de pronto para acrescentar um banco só se mexe na camada de acesso as de aplicação ficam inalteradas.
O ruim disto é que vc acaba por perder algumas facilidades que os sgbd´s tenham , pois senão vc teria que replicar uma trigger para varios bancos em varias liguagens diferentes.


Responder

Gostei + 0

19/08/2005

Adriano Santos

Uma solução e ter uma camada de acesso , não é simples , nem fácil , mas depois de pronto para acrescentar um banco só se mexe na camada de acesso as de aplicação ficam inalteradas. O ruim disto é que vc acaba por perder algumas facilidades que os sgbd´s tenham , pois senão vc teria que replicar uma trigger para varios bancos em varias liguagens diferentes.



Motta, poderia detalhar um pouco mais pra gente?
Em um exemplo simples como você faria? Quais componentes usaria? É importante para termos mais parâmetros para análise.

Valeu


Responder

Gostei + 0

19/08/2005

José Henrique

Adriano Santos
O Datasus fornece um propgrama para gerenciamento de banco de sangue gratuitamente, mas o usuário, normalmente hospitais públicos, têm que ter uma licensa o SQL Server o que inviabiliza, muitas vezes a adoção do programa. O hospital em que eu trabalho trabalha com Oracle e caso queira o programa, que é muito bom, terá que adquirir 1 licensa do SQL somente para usar este programa.


Responder

Gostei + 0

19/08/2005

Adriano Santos

[quote:4d8ae14db2=´José Henrique´]Adriano Santos
O Datasus fornece um propgrama para gerenciamento de banco de sangue gratuitamente, mas o usuário, normalmente hospitais públicos, têm que ter uma licensa o SQL Server o que inviabiliza, muitas vezes a adoção do programa. O hospital em que eu trabalho trabalha com Oracle e caso queira o programa, que é muito bom, terá que adquirir 1 licensa do SQL somente para usar este programa.[/quote:4d8ae14db2]

[b:4d8ae14db2]José Henrique[/b:4d8ae14db2], me desculpe mas não entendi sua resposta ao tópico que eu coloquei.
O que o Datasus e a aquisição do SQL tem a ver com este tópico?
Explique-se melhor meu caro.


Responder

Gostei + 0

19/08/2005

José Henrique

Adriano,
Se tivessem adotado o desenvolvimento que você propõe os usuários poderiam adotar o SGBD que quisessem. Lembrando que este programa foi feito atender a milhares de prefeituras (é de muito interesse do governo o bom gerenciamento da coleta e transfusão de sangue) com realidades diferentes (no nosso caso podemos pagar a licensa do Oracle, não faz sentido adquirir uma somente pra usar um determinado programa)


Responder

Gostei + 0

19/08/2005

Motta

[quote:5d6c800f60=´Adriano Santos´]
Uma solução e ter uma camada de acesso , não é simples , nem fácil , mas depois de pronto para acrescentar um banco só se mexe na camada de acesso as de aplicação ficam inalteradas. O ruim disto é que vc acaba por perder algumas facilidades que os sgbd´s tenham , pois senão vc teria que replicar uma trigger para varios bancos em varias liguagens diferentes.



Motta, poderia detalhar um pouco mais pra gente?
Em um exemplo simples como você faria? Quais componentes usaria? É importante para termos mais parâmetros para análise.

Valeu[/quote:5d6c800f60]


Nunca fiz isto, digo baseado em sistemas que vi e outras tecnologias :

Na camada de banco ficam todos os acessos e tratamentos relativos aos bancos (sintaxes etc)

Aqui também ficam as classes de acesso , as camadas de aplicação usam estas classes assim algo na aplicação ...

Cliente.Inserir(cod,nome,...);

Independe de banco , n camada de Acesso se faz os tratamentos necessários para acesso ao bd.

Limita-se também o padrão de criação de tabelas/colunas para que seja possível o uso em qualquer bd, não se usaria triggers/constraints etc pois a sintaxe varia e teria de ser ter redundancia de código em linguagens e ambientes diferentes, a integridade ficaria na aplicação (poderia até ficar no banco mas teria que se pesar o custo desta implementação)


Responder

Gostei + 0

19/08/2005

Adriano Santos

[quote:d5864c3338=´José Henrique´]Adriano,
Se tivessem adotado o desenvolvimento que você propõe os usuários poderiam adotar o SGBD que quisessem. Lembrando que este programa foi feito atender a milhares de prefeituras (é de muito interesse do governo o bom gerenciamento da coleta e transfusão de sangue) com realidades diferentes (no nosso caso podemos pagar a licensa do Oracle, não faz sentido adquirir uma somente pra usar um determinado programa)[/quote:d5864c3338]

Ah, entendi agora José Henrique, me perdoe pq não tinha interpretado direito sua resposta.

De fato, em determinados casos desenvolver uma aplicação Multi-Banco não faz sentido. Eu trabalhei com um sistema de escola que os clientes não tinham condição financeira para migrar para um banco de dados como o Oracle, então usávamos somente Interbase.


Responder

Gostei + 0

19/08/2005

Adriano Santos

Limita-se também o padrão de criação de tabelas/colunas para que seja possível o uso em qualquer bd, não se usaria triggers/constraints etc pois a sintaxe varia e teria de ser ter redundancia de código em linguagens e ambientes diferentes, a integridade ficaria na aplicação (poderia até ficar no banco mas teria que se pesar o custo desta implementação)


Entendi e concordo com você no que diz respeito a Triggers, Procedures e etc. Realmente teria bastante redundância de funções. Eu estudei uma vez a criação de procedures, views, triggers e etc em bancos Interbase, mas desisti de me aprofundar justamente por um motivo: portabilidade. Teria que refazer tudo em Oracle, SQLServer e etc;


Responder

Gostei + 0

19/08/2005

Motta

A questão é ter um requisito implementado por um objeto em um bd que não tem sequer corresponde em outro a solução seria re-implementar o requisito na aplicação ai o troço começa a ficar confuso.Falou-se em um banco de sangue de prefeituras , tipo da situação confusa, em Piraporinha do Mato Adentro com 1000 habitantes um Mysql , um Paradox ou até um Access resolve a parada , no Rio ou Sampa já se precisaria de um troço mais parrudo.Quando o sistema tem um escopo definido (um sistema de uma seguradora por exemplo) tem-se um perfil mais definido , assim o Sistema só roda em bancos mais parrudos (o que não quer dizer nada pois temos Oracle,Sybase,Caché,SqlServer...)


Responder

Gostei + 0

21/08/2005

Adriano Santos

A questão é ter um requisito implementado por um objeto em um bd que não tem sequer corresponde em outro a solução seria re-implementar o requisito na aplicação ai o troço começa a ficar confuso.Falou-se em um banco de sangue de prefeituras , tipo da situação confusa, em Piraporinha do Mato Adentro com 1000 habitantes um Mysql , um Paradox ou até um Access resolve a parada , no Rio ou Sampa já se precisaria de um troço mais parrudo.Quando o sistema tem um escopo definido (um sistema de uma seguradora por exemplo) tem-se um perfil mais definido , assim o Sistema só roda em bancos mais parrudos (o que não quer dizer nada pois temos Oracle,Sybase,Caché,SqlServer...)



Eu sempre digo o seguinte:

[color=green:6b985b0cc9]´O softaware bem programado funciona com qualquer BD´.[/color:6b985b0cc9]

Mas temos que lembrar sempre que o BD é importantíssimo quando se fala de volume de dados e de segurança. Como disse o Motta um programa como um banco de sangue, mesmo programado com eficiência, teria problemas com um MySQL, Paradox ou como ele mesmo disse com o Access em uma região onde o volume de informações é extremamente grande. Pra mim, cada caso é um caso.


Responder

Gostei + 0

22/08/2005

Motta

O que eu quis dizer é o seguinte, o Sistema tb tem de atender ao recurso financeiro disponível, fazer a melhor solução ao menor custo possível, um sistema pode ser perfeitamente seguro (contra falhas) em Access.
Ainda acho a solução de uma camada de acesso a melhor solução para multiplos planos.


Responder

Gostei + 0

22/08/2005

Adriano Santos

Com certeza Motta, o custo benefício para o cliente deve ser tanto por parte do software quanto do BD. Assino em baixo.


Responder

Gostei + 0

Utilizamos cookies para fornecer uma melhor experiência para nossos usuários, consulte nossa política de privacidade.

Aceitar