3. Usando Stored Procedures com Firebird e InterBase

3. Usando Stored Procedures

Nesse capítulo, abordaremos um dos assuntos mais interessantes do curso, a criação e uso de Stored Procedures dentro do banco de dados. Uma Stored Procedure funciona como uma função que fica armazenada dentro do próprio banco. Para que possamos manipular os dados e metadados presentes dentro do banco de dados o IB/FB dispõem de uma linguagem de programação personalizada e otimizada.

Uma Stored Procedure suporta declarações de variáveis, testes de condições, loops, comentários etc. Uma característica muito importante das Stored Procedures é que as mesmas são executadas dentro do próprio banco de dados, o que as faz serem extremamente rápidas, e o melhor, rodam no servidor, e não na máquina cliente.

Através do uso de Stored Procedures temos acesso a todas as instruções SQL do tipo DML (Linguagem de Manipulação de Dados).

O mais interessante é que podemos executar uma Stored Procedure de várias formas:

·Executar a Stored Procedure diretamente através de um editor SQL de uma ferramenta para gerenciamento do IB/FB, como o IBConsole e IBExpert, por exemplo;

·Como parte de uma instrução Select. Você pode definir uma Stored Procedure que retorna determinados valores ou até mesmo um ResultSet;

·A partir de outra Stored Procedure armazenada no banco de dados ou ainda fazendo sua execução de dentro de uma Trigger vinculada a alguma tabela do banco;

·Por último, podemos fazer a execução da Stored Procedure a partir de uma aplicação externa, escritas nas mais diversas linguagens de programação, como Delphi, C++, Java, Visual Basic etc.

O uso de Stored Procedures dentro do banco de dados, traz diversas vantagens as nossas aplicações. Existem hoje, no mercado, aplicações que possuem todas as suas regras de negócio contidas dentro do próprio banco de dados.

A maior vantagem, sem duvida alguma é o grande ganho de performance e redução do tráfego de rede proporcionado pelas mesmas. Veja abaixo algumas das principais vantagens na utilização de Stored Procedures:

·Centralização das regras de negócio no servidor e não na aplicação cliente. Quando uma determinada alteração precisar ser feita em alguma regra de negócio, a mesma é feita diretamente na Stored Procedure armazenada no banco de dados, não precisando assim redistribuir a aplicação cliente;

·Reduz consideravelmente o tráfego de rede, visto que na maioria das vezes o que irá trafegar serão somente parâmetros de entrada e saída;

·Todo o processamento das regras de negócio é executado no servidor, deixando assim a máquina cliente mais leve. Nesse cenário, onde as regras ficam armazenadas e são processadas no servidor, as máquinas clientes não requerem grandes configurações de processador e memória, visto que todo o processamento pesado está centralizado no servidor de banco de dados;

·Stored Procedures podem ser compartilhadas entre aplicações que utilizem um único banco de dados. Ao invés de implementarmos a regra de negócio em cada aplicação cliente, podemos defini-la dentro de uma Stored Procedure e fazer a chamada a partir de cada aplicação;

·Aumento na segurança das informações, visto que Stored Procedures podem executar operações em tabelas mesmo que os usuários não tenham privilégios de acesso sobre as mesmas. No entanto, é necessário que os usuários tenham privilégios de acesso para executar a Stored Procedure em questão.

Para que possamos utilizar Stored Procedures em nossos bancos de dados, devemos analisar as seguintes circunstâncias:

·Devemos analisar se a operação a ser executada pode ser feita completamente dentro do servidor, sem nenhuma interação com usuário da aplicação para obter informações enquanto a operação é executada. Lembrando apenas que Stored Procedures podem receber parâmetros de entrada no momento em que ela é chamada e pode retornar parâmetros de saída a aplicação que a chamou;

·Caso a operação necessite processar uma grande quantidade de registros, essa operação aumentaria o tráfego de rede para transportar os dados entre o banco de dados e a aplicação cliente;

·Caso a operação seja executada por aplicações ou módulos diferentes, essa operação pode ser armazenada numa Stored Procedure, para que todos possam compartilhar entre si;

·Operação que exija grande performance em sua execução ou que não possa ser executada a partir de uma aplicação cliente.

Criando Stored Procedures

Podemos criar uma Stored Procedure diretamente no editor SQL da ferramenta que utilizamos para gerenciar nosso banco de dados. Ferramentas como o IBConsole e IBExpert trazem consigo interfaces visuais para facilitar a criação e manutenção de Stored Procedures. Para criar um Stored Procedure devemos utilizar a instrução Create Procedure:

CREATE PROCEDURE NOME_DA_PROCEDURE LISTA_DE_PARAMETROS_DE_ENTRADA

RETURNS LISTA_DE_PARAMETROS_DE_SAIDA

AS

  LISTA_DE_VARIAVEIS_LOCAIS

  BEGIN

   CORPO_DA_PROCEDURE

  END;

Para a seção Nome_da_Procedure, devemos definir um nome único para a Stored Procedure, isso é, esse nome deve ser único entre todos os objetos armazenados no banco de dados. Para a seção Lista_de_Parametros_de_Entrada, podemos definir um ou mais parâmetros a serem passados para a Stored Procedure.

Na seção Lista_de_Parametros_de_Saida podemos definir os parâmetros a serem retornados pela Stored Procedure.

Na seção Lista_de_Variaveis_Locais podemos definir uma ou mais variáveis a serem utilizadas dentro do corpo da Stored Procedure. Finalmente, é na seção Corpo_da_Procedure que devemos escrever o código que será executado pela Stored Procedure.