Automatizando a atualização do banco de dados

O gerenciamento de scripts que realizam a atualização do banco de dados no cliente, em geral, gera problemas.

Primeiramente por que constantemente temos scripts que por algum motivo não foram executados e ocasionam erros no cliente, os quais geralmente conseguimos identificar pela mensagem e dizem respeito à falta de um campo que o script não criou ou atualizou.

Outra dificuldade ocorre por que em algum momento o cliente pode ter perdido algumas atualizações do sistema e quando se tenta executar o script da versão X até a Y com frequência temos problemas.

Além disso, é difícil efetuar o controle de versão desses scripts, pois não temos a possibilidade de rollback a menos que criemos um script separado para isso, sem contar que esses arquivos, com passar do tempo, vão ficando cada vez maiores.

Como resolver esse problema? Qual seria a melhor solução para isso? Uma alternativa de resolução para essa questão envolve a utilização de dicionários de dados, que serão explicados a seguir.

Dicionários e o banco de dados

O dicionário, nesse contexto, é uma estrutura de dados que contém a representação dos elementos do banco de dados. No contexto dos SGDBs, esses dicionários representam a estrutura do nosso banco, contendo informações como descrição dos objetos, restrições de integridade, stored procedures, triggers, índices, chaves e validações.

O uso de dicionários para representação da base de dados traz algumas vantagens que incluem maior facilidade para atualização do banco e para integração deste com a aplicação, que consegue mais facilmente reconhecer a estrutura das tabelas e exibir uma interface adequada para o usuário.

Neste caso teremos um arquivo com todas as definições do banco de dados e esse arquivo vai ser definido manualmente por nós, então podemos acrescentar nele algumas informações que poderão ser importadas e aproveitadas na aplicação.

Uma dessas informações cuja definição podemos otimizar é o caption da coluna, que geralmente atribuímos manualmente a cada label nas telas do sistema.

Utilizando a estratégia do dicionário podemos importar esse caption diretamente do arquivo de definição do banco de dados, com isso teremos o mesmo texto sendo exibido em qualquer tela do sistema onde aquele campo for utilizado. De forma análoga podemos atribuir descrições para os campos das tabelas e exibir essas informações como hint nos componentes.

A seguir temos detalhados alguns detalhes sobre como o uso de dicionários pode facilitar o desenvolvimento e manutenção de sistemas em Delphi.

Para o banco de dados:

· Garantia de que a estrutura esteja condizente com a realidade: o dicionário, neste caso, será um espelho de como o banco de dados deverá ficar;

· Arquivo de "script" fica menor: como não teremos mais arquivos de scripts, o arquivo de dicionário os substituirá. Esse arquivo, a longo prazo, será proporcionalmente menor que os scripts devido à não redundância das informações. Além disso, armazenar a estrutura de uma tabela é mais simples que armazenar seus comandos SQL equivalentes;

· Possibilidade de rollback: como o banco será estruturado de acordo com o dicionário, e este contém apenas a estrutura e não comandos SQL, fica fácil pegar a estrutura do dicionário e aplicar no banco, então para efetuar o rollback, basta utilizar a versão anterior do dicionário.

Para o sistema:

· Podemos utilizar o dicionário para definir se um campo é obrigatório, não tendo mais necessidade de deixar isso fixo no código. Em caso de um campo se tornar obrigatório ou não no dicionário, isso irá refletir no sistema sem codificação e na maioria das implementações sem a necessidade de rodar uma nova versão, tendo que apenas reenviar o dicionário para o cliente;

· Captions e Hints refletem no sistema sem a necessidade de códigos engessados. Assim como nos campos obrigatórios, em caso alterações não necessitamos de uma nova versão;

· Podemos criar domínios e validações exclusivas para um determinado grupo de colunas e empregá-las apenas informando no dicionário. Um exemplo ...