Artigos Delphi Controle de Scripts de Banco de dados - Revista ClubeDelphi 144
De que se trata o artigo

O artigo trata a criação de uma ferramenta para armazenamento e gerenciamento de Scripts de bancos de dados utilizando como plataforma de desenvolvimento o Delphi XE 2 e o banco de dados Firebird.

Em que situação o tema é útil

O tema é útil em casos onde se tem diversos tipos de SGDBs com estruturas em comum, porém, com Scripts diferentes. Desta forma é possível manter o histórico das alterações para possível gerenciamento, controle e posteriormente atualização dos bancos de dados.

Controle de Scripts de banco de dados

Organizar o desenvolvimento é algo muito importante para desenvolvedores, embora muitas vezes não seja priorizado devido a inúmeros fatores externos. Para facilitar estes processos de organização, pode-se optar pelo desenvolvimento de ferramentas personalizadas que atendam as necessidades internas de uma empresa, ou mesmo em situações de desenvolvedores independentes. Neste artigo, será abordada a criação de uma solução simples para gerenciamento e organização de Scripts de banco de dados com a finalidade de auxiliar nos processos de atualização.

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.

Nota do DevMan 1

O Inno Setup é um velho conhecido dos desenvolvedores Delphi. Basicamente é uma ferramenta que utiliza uma linguagem de Scripts (baseada em Pascal) para a criação de instaladores personalizados. Através desta ferramenta é possível realizar não só instaladores personalizados, como definir regras e interações com o ambiente (Sistema Operacional) além de possibilitar tarefas como executar arquivos, registrar bibliotecas, instalação de componentes, registro de servidores, copia de arquivos, downloads, entre muitas outras finalidades. Vale lembrar que a ferramenta é Free e possui não só a interface de Scripts, como um ambiente gráfico para facilitar em sua elaboração. Este ambiente pode ser instalado a parte a partir da ferramenta ISTool.

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.

Nota do DevMan 2

DDL é a sigla inglesa para “Data Definition Language”. Esta é uma linguagem que utiliza o padrão Ansi SQL para toda e qualquer manipulação relacionada à parte de estrutura de dados (em se tratando de banco de dados). É composta basicamente pelas instruções Create, Drop e Alter. Já outra famosa sigla, a DML (Data Manipulation Language) é a definição para a linguagem de manipulação das informações contidas em uma estrutura de dados, representada pelos comandos Insert, Delete, Update e Select (acrônimo CRUD).

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.

Nota do DevMan 3

Metadata nada mais é do que a definição ou estrutura de um banco de dados em forma de Script. Com ela é possível extrair ou compor até mesmo um banco de dados inteiro por meio de linguagem Ansi-SQL, permitindo assim a fácil importação, manipulação ou criação de estruturas inteiras, sejam elas complexas ou simples.

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.

...
Quer ler esse conteúdo completo? Tenha acesso completo