Quando usar procedimentos
Há uma série de vantagens em usar procedimentos, todas baseadas no fato de que o uso de procedimentos move instruções SQL do aplicativo para a fonte de dados. O que fica no aplicativo é uma chamada de procedimento interoperável. Essas vantagens incluem:
Desempenho Os Procedimentos geralmente são a maneira mais rápida de executar instruções SQL. Como a execução preparada, a instrução é compilada e executada em duas etapas distintas. Ao contrário da execução preparada, os procedimentos são executados somente em tempo de execução. Eles são compilados em outro momento.
Regras de negócio Uma regra de negócio é uma regra sobre a forma como uma empresa faz negócios. Por exemplo, apenas alguém com o título Vendedor pode ter permissão para adicionar ordens de venda novas. Colocar essas regras em procedimentos permite que empresas individuais personalizem aplicativos verticais reescrevendo os procedimentos que o aplicativo chama sem precisar modificar o código do aplicativo. Por exemplo, um aplicativo de entrada de pedido pode chamar o procedimento InsertOrder com um número fixo de parâmetros. O modo exato como o InsertOrder é implementado pode variar de empresa para empresa.
Capacidade de substituição Intimamente relacionada à impor regras de negócios em procedimentos está o fato de que os procedimentos podem ser substituídos sem recompilar o aplicativo. Se uma regra de negócios sofrer alterações depois que uma empresa tiver comprado e instalado um aplicativo, a empresa poderá alterar o procedimento que contém essa regra. Do ponto de vista do aplicativo, nada mudou. Ele ainda chama um procedimento específico para realizar uma tarefa específica.
SQL específico do DBMS Os procedimentos oferecem um modo de os aplicativos explorarem o SQL específico do DBMS e ainda permanecerem interoperáveis. Por exemplo, um procedimento em um DBMS que dá suporte a instruções de controle de fluxo no SQL pode interceptar e se recuperar de erros, enquanto um procedimento em um DBMS que não oferece suporte a instruções de controle de fluxo pode simplesmente retornar um erro.
Procedimentos sobrevivem a transações Em algumas fontes de dados, os planos de acesso para todas as instruções preparadas em uma conexão são excluídos ao confirmar ou reverter uma transação. Ao colocar as instruções SQL em procedimentos, que são armazenados permanentemente na fonte de dados, as instruções sobrevivem à transação. Se os procedimentos sobrevivem em um estado preparado, parcialmente preparado ou despreparado depende do DBMS.
Desenvolvimento separado Os procedimentos podem ser desenvolvidos separadamente do resto do aplicativo. Em grandes corporações, isso pode ser uma forma de explorar ainda mais as habilidades de programadores altamente especializados. Em outras palavras, programadores de aplicativos podem escrever código de interface do usuário e programadores de banco de dados podem escrever procedimentos.
Os procedimentos costumam ser usados por aplicativos verticais e personalizados. Esses aplicativos tendem a executar tarefas fixas, e é possível embutir em código chamadas de procedimento neles. Por exemplo, um aplicativo de entrada de ordem pode chamar os procedimentos InsertOrder, DeleteOrder, UpdateOrder e GetOrders.
Há poucos motivos para chamar procedimentos de aplicativos genéricos. Os procedimentos geralmente são escritos para executar uma tarefa no contexto de um aplicativo específico, portanto, não são úteis para aplicativos genéricos. Por exemplo, uma planilha não tem razão para chamar o procedimento InsertOrder mencionado acima. Além disso, aplicativos genéricos não devem construir procedimentos em tempo de execução na esperança de fornecer execução de instrução mais rápida. Não só é provável que isso seja mais lento do que a execução preparada ou direta, como também requer instruções SQL específicas do DBMS.
Uma exceção a isso são os ambientes de desenvolvimento de aplicativos, que costumam oferecer um modo de os programadores criarem instruções SQL que executam procedimentos e podem oferecer uma modo de os programadores testarem procedimentos. Esses ambientes chamam SQLProcedures para listar procedimentos disponíveis e SQLProcedureColumns para listar os parâmetros de entrada, entrada/saída e saída, o valor de retorno do procedimento e as colunas de todos os conjuntos de resultados criados por um procedimento. Porém, esses procedimentos devem ser desenvolvidos previamente em cada fonte de dados. Isso requer instruções SQL específicas do DBMS.
Há três grandes desvantagens no uso de procedimentos. A primeira é que os procedimentos devem ser escritos e compilados para cada DBMS com o qual o aplicativo deve ser executado. Embora isso não seja um problema para aplicativos personalizados, pode aumentar significativamente o tempo de desenvolvimento e manutenção para aplicativos verticais projetados para serem executados com vários DBMSs.
A segunda desvantagem é que muitos DBMSs não dão suporte a procedimentos. Mais uma vez, é mais provável que isso seja um problema para aplicativos verticais projetados para serem executados com vários DBMSs. Para determinar se há suporte para os procedimentos, um aplicativo chama SQLGetInfo com a opção SQL_PROCEDURES.
A terceira desvantagem, particularmente aplicável a ambientes de desenvolvimento de aplicativos, é que o ODBC não define uma gramática padrão para a criação de procedimentos. Ou seja, embora os aplicativos possam chamar procedimentos de modo interoperável, eles não podem criá-los de modo interoperável.