Quando usar procedimentos

Há várias vantagens em usar procedimentos, tudo com base no fato de que o uso de procedimentos move instruções SQL do aplicativo para a fonte de dados. O que resta 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. Assim como na execução preparada, a instrução é compilada e executada em duas etapas separadas. Ao contrário da execução preparada, os procedimentos são executados somente em tempo de execução. Eles são compilados em um momento diferente.

• Regras de negócios Uma regra de negócios é uma regra sobre como uma empresa faz negócios. Por exemplo, somente alguém com o título Sales Person pode ter permissão para adicionar novos pedidos de vendas. Colocar essas regras em procedimentos permite que empresas individuais personalizem aplicativos verticais reescrevendo os procedimentos chamados pelo aplicativo 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; exatamente como InsertOrder é implementado pode variar de empresa para empresa.

• Substituibilidade Intimamente relacionado à colocação de regras de negócios em procedimentos é o fato de que os procedimentos podem ser substituídos sem recompilar o aplicativo. Se uma regra de negócios for alterada 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 fornecem uma maneira 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 recuperar de erros, enquanto um procedimento em um DBMS que não dá 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 quando uma transação é confirmada ou revertida. Ao colocar 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 é específico do DBMS.

• Desenvolvimento separado Os procedimentos podem ser desenvolvidos separadamente do restante do aplicativo. Em grandes corporações, isso pode fornecer uma maneira de explorar ainda mais as habilidades de programadores altamente especializados. Em outras palavras, os programadores de aplicativos podem escrever código de interface do usuário e programadores de banco de dados podem escrever procedimentos.

Os procedimentos geralmente são usados por aplicativos verticais e personalizados. Esses aplicativos tendem a executar tarefas fixas e é possível codificar chamadas de procedimento nelas. Por exemplo, um aplicativo de entrada de pedido pode chamar os procedimentos InsertOrder, DeleteOrder, UpdateOrder e GetOrders.

Há pouca razão para chamar procedimentos de aplicativos genéricos. Os procedimentos geralmente são escritos para executar uma tarefa no contexto de um aplicativo específico e, portanto, não têm uso para aplicativos genéricos. Por exemplo, uma planilha não tem motivo para chamar o procedimento InsertOrder que acabou de ser mencionado. Além disso, aplicativos genéricos não devem construir procedimentos em tempo de execução na esperança de fornecer uma execução de instrução mais rápida; Isso não só provavelmente será 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 geralmente fornecem uma maneira para os programadores criarem instruções SQL que executam procedimentos e podem fornecer uma maneira para 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. No entanto, esses procedimentos devem ser desenvolvidos com antecedência em cada fonte de dados; Isso requer instruções SQL específicas do DBMS.

Há três grandes desvantagens em usar procedimentos. A primeira é que os procedimentos devem ser gravados e compilados para cada DBMS com o qual o aplicativo deve ser executado. Embora isso não seja um problema para aplicativos personalizados, ele 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. Novamente, isso provavelmente será um problema para aplicativos verticais projetados para serem executados com vários DBMSs. Para determinar se há suporte para procedimentos, um aplicativo chama SQLGetInfo com a opção SQL_PROCEDURES.

A terceira desvantagem, que é particularmente aplicável aos 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 interoperavelmente, eles não podem criá-los interoperavelmente.