Quando usar os procedimentos

Existem várias vantagens em usar procedimentos, todas baseadas no facto de que o uso de procedimentos move as instruções SQL da aplicação para a fonte de dados. O que resta na aplicação é uma chamada de procedimento interoperável. Estas vantagens incluem:

• Desempenho Os procedimentos são geralmente a forma mais rápida de executar instruções SQL. Tal como a execução preparada, a instrução é compilada e executada em dois passos separados. Ao contrário da execução preparada, os procedimentos são executados apenas em tempo de execução. São compilados em um momento diferente.

• Regras de Negócio Uma regra de negócio é uma regra sobre a forma como uma empresa faz negócios. Por exemplo, só alguém com o título de Vendedor pode ser autorizado a adicionar novas encomendas de venda. Colocar estas regras nos procedimentos permite que as empresas individuais personalizem aplicações verticais reescrevendo os procedimentos chamados pela aplicação sem ter de modificar o código da aplicação. Por exemplo, uma aplicação de entrada de ordens pode chamar o procedimento de InsertOrder com um número fixo de parâmetros; A forma exata como o InsertOrder é implementado pode variar de empresa para empresa.

• Substituibilidade Intimamente relacionado com a colocação de regras de negócio nos procedimentos está o facto de os procedimentos poderem ser substituídos sem necessidade de recompilar a aplicação. Se uma regra de negócio mudar depois de uma empresa ter comprado e instalado uma aplicação, a empresa pode alterar o procedimento que contém essa regra. Do ponto de vista da aplicação, nada mudou; Ainda assim, exige um procedimento específico para realizar uma tarefa específica.

• SQL específico para SGBD Os procedimentos permitem que as aplicações explorem SQL específico do SGBD e ainda assim permaneçam interoperáveis. Por exemplo, um procedimento num SGBD que suporta instruções control-of-flow em SQL pode capturar e recuperar erros, enquanto um procedimento num SGBD que não suporta instruções control-of-flow pode simplesmente devolver um erro.

• Procedimentos sobrevivem a transações Em algumas fontes de dados, os planos de acesso para todas as declarações preparadas numa ligação são eliminados quando uma transação é comprometida 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 permanecem num estado preparado, parcialmente preparado ou não preparado depende do SGBD.

• Desenvolvimento separado Os procedimentos podem ser desenvolvidos separadamente do resto da aplicação. Em grandes corporações, isto pode proporcionar uma forma de explorar ainda mais as competências de programadores altamente especializados. Por outras palavras, os programadores de aplicações podem escrever código de interface de utilizador e os programadores de bases de dados podem escrever procedimentos.

Os procedimentos são geralmente usados por aplicações verticais e personalizadas. Estas aplicações tendem a realizar tarefas fixas, e é possível codificar chamadas de procedimentos de forma fixa nelas. Por exemplo, uma aplicação de entrada de ordens pode chamar os procedimentos de InsertOrder, DeleteOrder, UpdateOrder e GetOrders.

Há pouca razão para chamar procedimentos a partir de aplicações genéricas. Os procedimentos são geralmente escritos para realizar uma tarefa no contexto de uma aplicação particular e, por isso, não têm utilidade para aplicações genéricas. Por exemplo, uma folha de cálculo não tem razão para chamar o procedimento InsertOrder mencionado agora. Além disso, aplicações genéricas não devem construir procedimentos em tempo de execução na esperança de proporcionar uma execução mais rápida de instruções; isto não só é provável que seja mais lento do que a execução preparada ou direta, como também requer instruções SQL específicas para SGBD.

Uma exceção a isto são os ambientes de desenvolvimento de aplicações, que frequentemente fornecem uma forma para programadores construírem instruções SQL que executam procedimentos e podem proporcionar uma forma de testar procedimentos. Tais ambientes chamam SQLProcedures para listar os 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 quaisquer conjuntos de resultados criados por um procedimento. No entanto, tais procedimentos devem ser desenvolvidos previamente em cada fonte de dados; para isso requer instruções SQL específicas para SGBD.

Existem três grandes desvantagens na utilização de procedimentos. A primeira é que os procedimentos devem ser escritos e compilados para cada SGBD com o qual a aplicação deve ser executada. Embora isto não seja um problema para aplicações personalizadas, pode aumentar significativamente o tempo de desenvolvimento e manutenção para aplicações verticais concebidas para funcionar com vários SGBD.

A segunda desvantagem é que muitos Sistemas de Gestão de Bases de Dados não suportam procedimentos. Mais uma vez, isto é provavelmente um problema para aplicações verticais desenhadas para funcionar com vários SGBD. Para determinar se os procedimentos são suportados, uma aplicação chama SQLGetInfo com a opção SQL_PROCEDURES.

A terceira desvantagem, particularmente aplicável a ambientes de desenvolvimento de aplicações, é que o ODBC não define uma gramática padrão para a criação de procedimentos. Ou seja, embora as aplicações possam chamar procedimentos de forma interoperável, não conseguem criá-los de forma interoperável.