Desmistificando o Execute Block - Revista ClubeDelphi 139

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.