Controle de Scripts de Banco de dados - Revista ClubeDelphi 144

Durante o cotidiano de qualquer empresa ou desenvolvedor, existem inúmeras tarefas que envolvem correções, alterações, testes, deploy, reuniões e muitas outras que surgem no decorrer dos dias. Embora os trabalhos sempre tenham prazos de entrega definidos com o cliente, raramente paramos para analisar a quantidade de tempo desprendido em tarefas simples, maçantes e por que não dizer, certas vezes realizadas até de forma “colossal”.

Grande parte das nossas rotinas diárias envolvem processos manuais que podem ser otimizados através de automatização de recursos. Para este tipo de situação, pode-se criar aplicações de suporte, que podem auxiliar não só na questão da otimização do tempo mas também na melhoria e organização dos departamentos de uma empresa. Como exemplo de algumas destas tarefas poderíamos citar a facilidade de distribuição de aplicações por meio de geração de instaladores como o Inno Setup (ver nota do DevMan 1), ferramentas de Backup automático e/ou agendado, atualizações automáticas do Software, geradores de documentação entre muitos outros.

Embora nem todas estas questões estejam diretamente relacionadas com o desenvolvimento, algumas são comuns na maioria dos ambientes de desenvolvimento. Um exemplo deste tipo de tarefa é exatamente o tema principal deste artigo, a organização dos Scripts de bancos de dados.

Utilizar uma abordagem de concentrar a regra de negócio na aplicação ou no banco de dados sempre é tema de longas discussões entre desenvolvedores, e há pontos positivos e negativos em ambas as abordagens, embora nenhuma esteja errada, uma boa dica para este tipo de situação é sempre pesar o que deve estar na aplicação ou não, considerando neste caso principalmente se você deseja ou não ter portabilidade independente do SGDB, entre outros fatores. Deixando esse assunto um pouco de lado, é comum desenvolvedores fazerem um trabalho de administração de banco e desenvolvimento, realizando a manutenção no banco de dados e na aplicação, abordando assim operações de alteração de estrutura, correções ou adaptações por meio de instruções DDL/DML (ver nota do DevMan 2), ou mesmo alteração de objetos previamente criados como Domains, Procedures, Triggers, Sequences, manutenção de índices e etc.

A dificuldade, no entanto, muitas vezes está em manter uma estrutura organizada para manipular este Metadata (nota do DevMan 3). O problema pode ser ainda mais agravante em situações que existem diferentes clientes com versões diferentes do mesmo aplicativo. Isto porque o processo de atualização do aplicativo pode se tornar extremamente trabalhoso e dependendo dos casos, até mesmo arriscado, gerando grandes dores de cabeça e fazendo com que muitas SoftHouses temam o processo de atualização do próprio Software.

Ainda se tratando de banco de dados, imagine uma situação onde o volume de alterações na base é grande. Isto é algo comum, em aplicações que possuem as regras de negócio todas concentradas diretamente no banco de dados. Assim sendo, na adição de novos recursos ao Software, o impacto destas alterações é grande, envolvendo uma série de objetos que devem ser alterados/criados. Um exemplo disso são as constantes alterações que aplicações comerciais e industriais vem sofrendo, principalmente na parte de legislação, envolvendo nota fiscal eletrônica e o SPED. Existem ainda raras situações onde sua aplicação deverá funcionar em uma empresa com um departamento de TI integrado, que neste caso poderá exigir que o Software utilize um banco de dados específico. Caberia neste quadro uma possível conversão/migração de dados, o que ocasionaria em mais Scripts a serem manipulados.