Stored Procedures

O comando Stored Procedure, em português ‘Procedimento Armazenado’, também é conhecido como Procedure ou Proc. Na linguagem SQL uma Stored Procedure serve para armazenar uma relação de instruções que devem ser executadas.

Quem utiliza o SQL e possui instruções que devem ser executadas repetidamente, certamente utilizará uma Stored Procedure, pois o intuito deste comando é fazer com que as rotinas sejam executadas de forma mais ágil e eficiente, sem ter que ficar escrevendo o mesmo código repetidamente várias vezes. Stored Procedures são úteis também para proteger um Banco de Dados limitando ações de usuários leigos. 

Uma Stored Procedure na linguagem SQL nos dá a possibilidade de utilizar variáveis e a estrutura lógica de uma linguagem de programação, tal como o comando View.
 
Uma das vantagens de usar uma Stored Procedure é que ela fica pré-carregada no servidor de banco de dados SQL apenas esperando ser chamada para executar as tarefas, assim conseguimos resultados mais rápidos. Em bancos de dados muito pesados, uma Stored Procedure demonstra um desempenho fantástico e muito mais velocidade que outros métodos.

Acompanhe abaixo um exemplo de como criar uma Stored Procedure no SQL Server: 

create procedure altualiza_tel (@cod int, @ddd varchar(3), @telefone varchar (8)) as 
update clientes set ddd= @ddd, telefone = @telefone 
where codigocliente = @cod 


Após executar a criação da Stored Procedure, ela já estará armazenada no banco de dados, no servidor SQL Server, e para executá-la basta utilizar o seguinte comando: 

Atualiza_tel 1293, ‘11’, ‘32847388’ 

Ou seja, para executar Stored Procedure, basta colocar o nome dado à Stored Procedure e em seguida os valores de atribuição às variáveis na mesma ordem que foram indicadas entre os parênteses da primeira linha do comando de criação. Fazendo a leitura do comando de execução:
 
Nome_da_Stored_Procedure codigo_cliente, ddd, telefone 

Deste modo, com a Stored Procedure criada no exemplo acima, não será mais necessário escrever o ‘update’ para atualizar o telefone dos clientes: a execução será mais rápida e pode ser usado em sistemas fora do ambiente de desenvolvimento SQL. 

  • Vantagens:

  • Reduzir o tráfego de rede : se o cliente estiver enviando uma grande consulta e talvez esteja usando a mesma consulta com muita freqüência, cada bit da consulta é enviado para a rede e, portanto, o que pode aumentar o tráfego de rede e aumentar o uso da rede desnecessário.

  • Execução mais rápida da consulta : uma vez que os stored procedures são analisados, compilados de uma vez e o executável é armazenado em cache no database. Portanto, se a mesma consulta for repetida várias vezes, o database executa diretamente o executável e, portanto, o tempo é salvo no Parse, Compile etc. Isso é bom se a consulta for usada com freqüência. Se a consulta não for usada com freqüência, talvez não seja bom, porque armazenar executável em cache leva espaço, por que colocar Load on Database desnecessariamente.

  • Modular : se várias aplicações quiser usar a mesma consulta, então, de maneira tradicional, você está duplicando o código desnecessariamente em aplicativos, a melhor maneira é colocar o código perto do database, assim a duplicação pode ser facilmente aliviada.

  • Segurança : os stored procedures também são desenvolvidos, tendo em mente a Autorização (significa quem é o privilégio de executar a consulta e quem não é). Por isso, para um usuário específico, você pode conceder permissions, para outras pessoas você, como DBA, pode revogar a permissão. Então, é uma boa maneira como um ponto para os DBAs um DBA você pode saber quem é a pessoa certa para obter o access. Mas essas coisas não são tão populares agora, você pode projetar seu database de aplicativos de tal forma que apenas a pessoa autorizada possa acessá-lo e não todos. Então, se você tiver apenas Segurança / Autorização como o ponto de usar os Procedimentos Armazenados em vez da maneira convencional de fazer as coisas, então o procedimento armazenado pode não ser apropriado.