Artigos Delphi Desmistificando o Execute Block - Revista ClubeDelphi 139
De que se trata o artigo

O artigo trata de ilustrar o Execute Block, um recurso específico do Firebird que assim como Procedures, permite a utilização da linguagem PSQL para a criação de procedimentos mais elaborados de forma dinâmica, sem a necessidade de alocar o objeto no banco de dados.


Em que situação o tema é útil

O tema é útil em casos onde é necessário realizar alterações a partir de seleções complexas, o que demandaria a criação de uma Procedure, trazendo consigo a vantagem de executar qualquer comando presente em PSQL de forma simplificada, sem a necessidade de ser efetivamente criado no banco de dados.

Desmistificando o Execute Block

Em situações de atualizações de Software, ou mesmo procedimentos que envolvem grandes quantidades de alterações, sempre é comum os desenvolvedores ou administradores do banco de dados utilizarem recursos da linguagem PSQL para criar Procedures que permitam operações de manipulação de várias tabelas, inserções, atualizações, alterações, adaptações entre outras diversas situações. Em muitos destes casos, estas Procedures são criadas unicamente para realização destes procedimentos, porém, esquecidas, acabam se tornando apenas objetos inúteis no banco de dados. O objetivo é demonstrar um recurso presente desde a versão 2.0 do Firebird, na qual permite a execução de blocos de PSQL de maneira dinâmica, de forma desacoplada do banco de dados, ilustrando além de sua finalidade as formas e maneiras de como utilizá-lo em diversas ocasiões do cotidiano.

Utilizar recursos do banco de dados é algo que sempre rende boas discussões entre desenvolvedores. Há quem diga que o banco de dados deve funcionar como mero repositório de dados, assim como há quem diga que se deve aproveitar ao máximo os recursos disponíveis em um SGDB. É claro que esta questão possui prós e contras. Uma dessas vantagens de se utilizar os recursos de banco de dados é a autonomia para a realização de procedimentos automáticos de maneira transparente à aplicação, como baixa de estoque, geração de contas a pagar/receber, geração de duplicatas entre muitas outras coisas. Práticas comuns do cotidiano, muitas destas rotinas citadas são utilizadas em forma de Procedures no banco de dados.

Em uma situação real, de uma venda, pode-se realizar a baixa do estoque dos produtos selecionados, criar um lançamento no contas a receber (quitando ou não o lançamento), emitir a nota fiscal, lançar a comissão do vendedor, entre tantas outras funcionalidades comuns a um Software comercial. Como tudo há vantagens e desvantagens, o lado negativo é que para isso, há a necessidade de se criar alguns conjuntos de objetos específicos para essas ações, como as Procedures, já mencionadas, e Triggers para validações necessárias, e isto, pode fazer com que a aplicação fique muito dependente do banco de dados. Embora isto não seja uma regra, uma boa prática é sempre avaliar o custo/benefício de se criar os recursos em aplicação ou banco de dados, procurando manter um equilíbrio entre ambos e não tornando a aplicação totalmente dependente do banco de dados, facilitando em caso de uma futura migração. Além destas questões já comentadas, deve-se avaliar também o ambiente. O excesso de objetos (Triggers em particular) pode causar certa redução de desempenho, o que em caso de uma ambiente Web, torna-se completamente inviável.

Embora haja inúmeras questões que podem ser levadas em conta, um dos grandes problemas em Software Houses são as atualizações. Independente de se utilizar as regras concentradas em aplicação, não há como escapar das alterações em DDL. Como se sabe, se o volume de alterações no banco de dados é grande, logicamente haverá uma grande quantidade de Scripts a serem executados no momento da atualização, o que pode demandar um pouco mais de trabalho por parte da equipe de suporte, ou do próprio Software se o mesmo se “auto-atualiza”. Independente de adotar a metodologia de centralização das regras no banco de dados ou não, uma coisa é certa, não há como fugir de alterações no SGDB.

Um exemplo claro destas dificuldades mais do que nunca está presente agora. Com as recentes exigências do governo em relação à fiscalização (SPED, NF-e, CT-e entre tantos outros), as Software Houses estão adequando seus produtos as conformidades estabelecidas pelo governo. E nestes casos, as alterações no banco de dados em parte estrutural (DDL) ou mesmo em dados já consistentes, tornaram-se tarefa comum aos desenvolvedores, administradores ou DBAs em geral.

Em se tratando deste tipo de atualização, comumente quando há grandes alterações estruturais que envolvem criação de várias tabelas, importação de dados através de arquivos, planilhas ou algo do tipo, são criados procedimentos no banco de dados que realizam este tipo de tarefa, buscando informações de diversas tabelas para “compor” outras, validando dados e os persistindo em seguida, criações de tabelas temporárias (Global Temporary Tables) ou auxiliares, entre tantas outras necessidades. Neste tipo de situação as únicas maneiras de se trabalhar com várias tabelas simultaneamente, eram desenvolver pequenos aplicativos que realizassem o trabalho de conexão com o banco de dados, seleção de tabelas, manuseio dos dados e etc, apenas para realizar estes procedimentos. Ou utilizando a segunda opção, na qual era trabalhar com Procedures criadas unicamente para estes fins, que executassem estas tarefas e fizessem o trabalho árduo, sendo logo em seguida excluídas, ou, em muitos casos, nem mesmo isso, tornando-se apenas objetos inúteis e contribuindo com o crescimento excessivo do banco de dados de forma errada.

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