Artigos Banco de Dados 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. <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Nota: Stored Procedures suportam instruções DDL (Linguagem de Definição de Dados), isso é, você não consegue executar instruções de Create, Alter, Drop, Grant, Revoke, dentro a partir de uma Stored Pprocedure.
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.
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.
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.
Nota: O uso de parâmetros de entrada não é obrigatório.
Na seção Lista_de_Parametros_de_Saida podemos definir os parâmetros a serem retornados pela Stored Procedure.
Nota: O uso de parâmetros de saída não é obrigatório.
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.
Definindo Parâmetros de Entrada e Saída
Durante a definição de uma Stored Procedure, podemos definir parâmetros de entrada e de saída para a mesma. Uma lista de parâmetros de entrada representa uma lista de variáveis que são passadas pela aplicação cliente para a Stored Procedure. Essas variáveis, podem ser utilizadas dentro da Stored Procedure para modificar seu comportamento, fazendo parte de cálculos ou de filtros em instruções SQL, por exemplo.
Suponhamos que exista uma Stored Procedure para calcular as vendas de um determinado cliente, nesse caso, devemos especificar um parâmetro de entrada onde passaremos o código do cliente o qual terá suas vendas processadas. Uma lista de parâmetros de saída, representa os valores de retorno que a Procedure pode passar de volta para a aplicação cliente que a chamou. Veja a seguir, a sintaxe básica para a definição da lista de parâmetros da Stored Procedure:
NOME_DO_PARAMETRO1 TIPO_DO_PARAMETRO,
NOME_DO_PARAMETRO2 TIPO_DO_PARAMETRO,
NOME_DO_PARAMETRON TIPO_DO_PARAMETRO
O nome do parâmetro é qualquer nome válido para uso dentro do IB/FB, isso é, o mesmo deve ser único dentro da Stored Procedure, não pode possuir caracteres especiais, e nem espaços em branco. O tipo do parâmetro pode ser qualquer tipo de dados válido suportado pelo IB/FB, exceto os tipos BLOB, Domain e tipos de dado Array.