Você está na página 1de 4

O que é Stored Procedure?

Um procedimento armazenado é um código SQL preparado que você pode


salvar, para que o código possa ser reutilizado continuamente.

Portanto, se você tiver uma consulta SQL que escreve repetidamente, salve-a
como um procedimento armazenado e, em seguida, apenas chame-a para
executá-la.

Você também pode passar parâmetros para um procedimento armazenado, de


modo que o procedimento armazenado possa agir com base nos valores dos
parâmetros que são transmitidos.

Quando utilizar procedures?

 Quando temos várias aplicações escritas em diferentes linguagens, ou


rodam em plataformas diferentes, porém executam a mesma função.
 Quando damos prioridade à consistência e segurança

Há Cinco Tipos De Procedures Básicos Que Podemos Criar:

 Procedimentos Locais: São criados a partir de um banco de dados do


próprio usuário;
 Procedimentos Temporários: Existem dois tipos de procedimentos
temporários: Locais, que devem começar com # e globais, que devem
começar com ##;
 Procedimentos de Sistema: Armazenados no banco de dados padrão do
SQL Server (Master), podemos identificá-los com as siglas sp, que se
origina de Stored procedure. Tais procedures executam as tarefas
administrativas e podem ser executadas a partir de qualquer banco de
dados.
 Procedimentos Remotos: Podemos usar Queries Distribuídas para tais
procedures. São utilizadas apenas para compatibilidade.
 Procedimentos Estendidos: Diferente dos procedimentos já citados, este
tipo de procedimento recebe a extensão .dll e são executadas fora do
SGBD SQL Server. São identificadas com o prefixo xp.
Por que é mais seguro?

Seguindo a linha de raciocínio dos bancos, utilizando stored procedures outras


aplicações e usuários não conseguiriam nenhum tipo de acesso às tabelas do
banco de dados de forma direta.

Eles poderiam apenas executar os stored procedures, que rodam ações


específicas e determinadas pelos DBAs e desenvolvedores.

O uso de stored procedure para melhoria de performance e de segurança é,


essencial para uma aplicação web, se tornando um fator de comparação entre
aplicativos de médio e grande porte. Em contra partida temos a dependência
que criamos com o sistema de banco de dados e a carga de processamento
que passamos para nosso servidor, mas se pesados e usados de forma correta
as stored’s procedures são uma ferramentas excelentes.

Primeiro Exemplo de aplicação:

#WebService Ou uma Api- Consulta com passagem de parâmetro

Duas aplicações um web service feito em C# e uma aplicação desktop feita em


Delphi precisam rodar uma regra de negócio implementada no BD. Para melhor
manutenção e gerencialmente é melhor que ambas acessem a mesma SP ao
invés de cada uma tentar implementar uma query. Assim qualquer mudança
nessa lógica seria feita alterando a SP ao invés de gerar manutenção em dois
sistemas distintos. Note que o mesmo resultado poderia ser obtido se ambas
as aplicações pudessem chamar uma DLL que encapsula-se essas regras de
negócio (a menos que rodem em diferentes SO).

Segundo exemplo aplicando para performance:

Algumas rotinas ficam realmente muito mais rápidas se implementadas


diretamente no BD. Embora eu seja a favor de manter as regras de negócio na
camada de regras de negócio tem vezes que é inevitável. Nesses caso a rotina
pode ser implementada como uma SP, como a SP fica armazenada
"compilada" no BD pode haver um ganho de performance se essa rotina é
chamada muitas (milhares de) vezes (por dia/hora). Claro isso depende se
comparada queries que não são parametrizadas, etc. Mesmo usando SP pode
haver considerações sobre SQL Inject (segurança) e Parameter Sniffing
(performance)

Os casos 1 e 2 também podem ser vantajosos naquelas circunstâncias onde


você faz um SELECT gigante com várias tabelas e a aplicação cliente usa isso
pra agrupar, totalizar ou fazer algum outro processamento. Você consegue
reduzir o tráfego de rede entre o servidor de banco de dados e a aplicação
cliente, e com isso melhorar a performance, se essas operações forem
realizadas diretamente pelo SGBD por meio de Stored Procedures.

Pesquisa sobre Stored Procedure

Integrantes:

Lucas Eduardo Moraes Lage

Samuel Borges De Aquino

Vinicius Jose Da Silva Costa

Rian Da Costa Silva

Você também pode gostar