Quando desenvolvemos um aplicativo baseado na plataforma web geralmente sabemos em qual host iremos hospedá-lo, mas não sabemos como é a estrutura de servidores, se o servidor de bancos de dados é o mesmo servidor de aplicativos ou se são servidores diferentes, o que pode comprometer em muito o desempenho da aplicação.
Imagine uma situação X em que os servidores são separados fisicamente por grandes distancias, por exemplo, um servidor no Brasil e outro servidor nos E.U.A, agora e se nossa aplicação necessita fazer uma requisição de dados muito pesada, por mais que o link de internet seja muito bom ou mesmo seja uma VPN ( no caso de empresas grande que tem servidores espalhados por diversas partes) teríamos uma queda no desempenho quando comparado com uma situação Y onde temos os dois servidores(web e banco de dados) na mesma maquina ou separados por uma distância menor. Acontece que quando enviamos uma solicitação de consulta através de nossa aplicação para o servidor de banco de dados passamos toda uma string diga-se de passagem, complexa, uma vez que é composta de muito texto e números - de consulta que após chegar ao servidor será interpretada pelo engine  do banco de dados e então será executada , após isso o valor será retornado para a aplicação fazendo o caminho inverso dependendo de como cada sistema de bancos de dados tem seu tipo de retorno.

Agora imagine com é a estrutura de uma consulta para formular um relatório (id,nomeFunc,NomeSetor,IdFunc,IdSetor,Salario,etc. dentre outros campos que estão separados por muitas tabelas) ou de uma inserção de dados em determinadas tabelas por exemplo, especificamos muitos dos campos o que pode vir a ser comprometedor se algum hacker ou cracker vier a interceptar uma vez que passamos uma string  que pode ser lida sem dificuldade já que sua estrutura é padrão em quase todos os casos. Para isso temos um recurso muito comum, existente na maioria dos bancos de dados relacionais de hoje as stored procedures (procedimentos armazenados), que são nada mais do que métodos que criamos,compilamos e executamos a partir de nossa base de dados e que ao serem invocadas em nossa aplicação necessita apenas da passagem dos valores que queremos inserir ou realizar qualquer outra operação e se for uma consulta podemos apenas passar nossos filtros. Fica claro que o trafego é bem menor na rede uma vez que os valores passados são poucos, ou nenhum valor é passado – ao invés de passarmos toda a query - com isso deixamos o processamento de todas as informações para o servidor de banco de dados que tem sua estrutura (tanto física, quanto lógica) preparada para isso, o que torna o processamento menos trabalhoso para ele do que seria para o web server ao enviar a consulta - deixando o servidor de paginas mais livre para processar de maneira mais leve e rápida as requisições. É claro que ao livrarmos o servidor web aplicamos uma carga de dados muito grande no servidor de banco, então é de grande valia que tomemos cuidado para não fazer todo e qualquer método no servidor e se possível nos atermos apenas em fazer isso com os mais pesados (que consomem mais processamento) ou os que geram mais riscos no caso de interceptação, por que, se fizermos todo tipo de procedimento no servidor de banco estaremos sujeitos, dependendo do numero de acessos que tivermos, a derrubar nosso servidor de banco de dados. Mas é claro que devido ao fato desses procedimentos serem compilados o servidor já sabe de antemão o que vai fazer o que torna o serviço menos árduo para ele.
É visto também que não sentiremos isso, se a modelagem da base não for bem feita ou se a estrutura não for compatível com o projeto a ser desenvolvido, mas quando aplicado a sistemas de grande porte temos um ganho de desempenho enorme.
Até agora foram apresentadas as vantagens da utilização de stored procedures, agora falaremos um pouco sobre as desvantagens do uso delas. Como já dissemos uma desvantagem do seu uso é que aplicamos uma carga e um fluxo de dados muito grande no servidor de banco de dados mais além deste existe outro fator que influencia na hora da tomada de decisão sobre usar ou não stored procedures, é que fazendo isso ficamos muito dependentes da base de dados, e se por acaso haver a necessidade de mudarmos de base por algum motivo qualquer seriamos obrigado a reescrever todas as storeds procedures o que seria muito trabalhoso se existirem muitas na base.Existem no mercado ferramentas que fazer essa migração, porém em alguns casos é necessário fazer a reescrita da mesma.

CREATE PROCEDURE <nome>
            @param1
WITH ...
AS
            <bloco de comandos>
GO


Por exemplo, essa é a estrutura de uma stored procedure em Microsoft SQL Server 2005, onde temos a declaração dão procedimento, a declaração das variáveis – que é outro fator muitas vezes incompatível na hora de migrar a base – e o bloco do procedimento.

CREATE [OR REPLACE] PROCEDURE [schema.]nome

[(param1 [modo1] tipodedado1,

               param2 [modo2] tipodedado2,

               ...)]

IS|AS

Bloco PL/SQL

 


Aqui temos uma procedure criada em Oracle, onde temos a mesma estrutura base do outro exemplo , porém a disposição é diferente.

CREATE PROCEDURE <nome> [( {opcional params })]
[{ opcional procedure attributes }]

BEGIN [atomic]

            <Bloco SQL>
END


Aqui temos um exemplo de procedure em IBM DB2, onde podemos comparar com clareza algumas diferenças entre alguns sistemas de bancos de dados
 
Conclusão
 

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 storeds procedures são uma ferramentas excelentes.