Olá pessoal, na coluna de hoje vou falar um pouco sobre Stored Procedures, um recurso valioso para o desenvolvimento de aplicações e performance.

Stored Procedures nada mais são do que um conjunto de instruções Transact-SQL que são executadas dentro do banco de dados. É como escrever um programa dentro do próprio banco de dados para executar tudo lá dentro.

Dentro das Stored Procedures devemos utilizar comandos Transact-SQL que não deixam nada a desejar a comandos de uma liguagem de programação qualquer, como Visual Basic ou Delphi. O Transact-SQL possui instruções de comparação (if), loops (while) operadores, variáveis, funcões, etc.

Vamos ver um exemplo:

CREATE PROCEDURE TESTE
AS
BEGIN
SELECT ‘O FAMOSO HELLO WORLD!’
END

Perceba que os comandos de início e término de bloco, BEGIN e END respectivamente, são obrigatórios no início e fim do comando.

Bom, podemos receber parâmetros, e utilizarmos eles em instruções SQL que serão executadas dentro da Stored Procedure:

CREATE PROCEDURE TESTE @PAR1 INT
AS
BEGIN
UPDATE TABELA1 SET CAMPO1 = ‘NOVO_VALOR’
WHERE CAMPO2 = @PAR1
END

Percebam que no exemplo acima, não utilizamos parênteses, pois Stored Procedures são um pouco diferentes de funções.

Como uma Stored Procedure fica armazenada no banco de dados, ela ja é pre-compilada e o SQL Server a executa mais rapidamente. Um exemplo de execução desta Stored Procedure, no Query Analyzer:

/* Chama a Stored Procedure TESTE passando 10 como primeiro parâmetro */

EXECUTE TESTE 10

Outra vantagem das Stored Procedures é que um programa chamador, seja ele uma página ASP ou um programa em VB, Delphi, Java, etc, só precisa chamar o nome da Stored Procedure, que pode conter diversos comandos Transact-SQL embutidos dentro dela, evitanto assim um tráfego de rede maior, resultando em resposta mais rápida.

Uma Stored Procedure pode ainda retornar valores para a aplicação. Aqui temos um detalhe: o SQL Server permite o retorno de dados em forma de uma tabela após a execução ou um valor de retorno normal. Exemplo:

CREATE PROCEDURE TESTE @PAR1 INT
AS
BEGIN
SELECT @PAR1*@PAR1 AS QUADRADO
END

No exemplo acima a aplicação chamadora (cliente) pode capturar o retorno da Stored Procedure através do campo chamado QUADRADO, que contém somente um valor de retorno: o parâmetro elevado ao quadrado. Agora no próximo exemplo:

CREATE PROCEDURE TESTE @PAR1 INT
AS
BEGIN
SELECT CAMPO1 , CAMPO2 FROM TABELA1
WHERE CAMPO3 = @PAR1
END

Retorna para o cliente uma tabela contendo dois campos, CAMPO1 e CAMPO2, e podem ser capturados pela aplicação chamadora como se fossem uma tabela.

O uso de Stored Procedure é encorajado, mais deve-se utilizar este recurso com cuidado pois se utilizado em excesso o SQL Server pode ser sobrecarregado, mas ao mesmo tempo podemos obter um ganho de performance considerável, dependendo do caso. Minhas ‘regrinhas’ para o uso de Stored Procedures:

. Não faça Stored Procedures que somente fazem um Select ou Update ou Delete. Para isso envie a instrução diretamente;

. Use sempre transações, para poder ‘voltar’ os dados em caso de problemas;

. Retorne somente o necessário, evitanto tráfego na rede desnecessário;

. Use uma nomeclatura coerente para as Stored Procedures e as variáveis dentro dela;

. Sempre idente seu código ao entrar em uma estrutura de bloco;

. Comente o máximo possível do seu código através do -- ou do /* e */

Abraço!