Artigo Clube Delphi 75 - Aplicações MultiBanco

Banco de dados

Aplicações multibanco

Adapte sua aplicação para funcionar com diferentes BDs, usando técnicas de desenvolvimento em camadas e POO

Toda software house, ao desenvolver seus produtos, tem que viabilizar seus softwares para serem adquiridos pelo número máximo possível de clientes, independente do SGBD que o cliente utilizar. O objetivo deste artigo é mostrar como desenvolver software nessas condições, escrevendo o código-fonte uma única vez, e que possa funcionar para diferentes SGBDs, como Oracle, SQL Server, Firebird e PostgreSQL.

Para tanto, é necessário resolver problemas de compatibilidade entre os diferentes SGBDs, como tipos de dados e funções. Também deve-se criar uma arquitetura incluindo uma camada de persistência, capaz de gerenciar adequadamente o acesso a dados.

Criação de tabelas

Todos os fornecedores de BDs se propõem a armazenar os principais tipos representáveis de dados em tabelas, sendo que alguns têm mais opções do que os outros. Quem trabalha com mais de um fornecedor, provavelmente já investiu um tempo para pesquisar as ferramentas CASE ou para modelagem de diagramas E-R. A maioria delas possui o recurso de traduzir o modelo especificado para os diferentes fornecedores de SGBD, respeitando as suas diferenças.

Para criar uma ferramenta desse tipo para a sua aplicação, você terá que em um primeiro momento delimitar quais os bancos de dados que pretende trabalhar, e realizar um estudo dos tipos compatíveis entre eles. Na Tabela 1 estão relacionados os tipos mais comuns em cada banco de dados e o equivalente nos outros SGBDs tratados neste artigo.

Tabela 1. Tipos de dados dos SGBDs

É importante considerar que além dos tipos de dados relacionados na Tabela 1, também existem tipos similares, que possuem funções específicas. Por exemplo: o tipo nvarchar no SQL Server também armazena valores alfanuméricos, porém usa a codificação Unicode, usada para representação de caracteres de línguas específicas como o japonês. Quanto à sintaxe da instrução Create, quando forem usadas as opções básicas da instrução, o comando é padrão para todos os bancos, conforme exemplo na Listagem 1.

Listagem 1. Instrução de criação de uma tabela (tipos do SQL Server)

Create Table Cliente

  (IDInt Not Null,

   CodigoInt Not Null,

   Nome Varchar(40) Not Null,

   EnderecoVarchar(40),

 Constraint PK_Cliente Primary Key(ID));

A manutenção das tabelas utiliza praticamente uma sintaxe padrão. Uma exceção são as versões anteriores do Oracle, que não permitem retirar um atributo da mesma, sendo necessário salvá-la em outra temporária, recriá-la sem o campo e restaurar as informações para a tabela original.

Triggers/Stored Procedures

A vantagem de se utilizar Triggers e Stored Procedures é que você consegue colocar as regras do negócio da aplicação no banco de dados, agilizando alguns procedimentos e, principalmente, protegendo a integridade dos dados independentemente do aplicativo que está acessando as informações. Entretanto a portabilidade da aplicação é inversamente proporcional ao uso dos mesmos.

As instruções SQL são padronizadas pelo padrão ANSI e por isso possuem uma boa similaridade entre os diversos fornecedores de SGBD, porém a linguagem empregada no desenvolvimento de Triggers e Stored Procedure não é controlada por nenhum padrão e cada fornecedor possui uma linguagem que geralmente é incompatível com os outros fornecedores.

Resumindo você terá que dar manutenção em tantas fontes quantos forem os bancos de dados onde a sua aplicação irá executar. Na " [...] continue lendo...