Cuándo se debe utilizar procedimientos
Hay una serie de ventajas para usar procedimientos, todos basados en el hecho de que el uso de procedimientos mueve instrucciones SQL de la aplicación al origen de datos. Lo que queda en la aplicación es una llamada a procedimiento interoperable. Estas ventajas incluyen lo siguiente:
Los procedimientos de rendimiento suelen ser la forma más rápida de ejecutar instrucciones SQL. Al igual que la ejecución preparada, la instrucción se compila y se ejecuta en dos pasos independientes. A diferencia de la ejecución preparada, los procedimientos solo se ejecutan en tiempo de ejecución. Se compilan en otro momento.
Reglas de negocios Una regla de negocios es una regla sobre la forma en que una empresa hace negocios. Por ejemplo, solo se puede permitir que alguien con el título Comercial agregue nuevos pedidos de ventas. La colocación de estas reglas en procedimientos permite a las empresas individuales personalizar las aplicaciones verticales mediante la reescritura de los procedimientos llamados por la aplicación sin tener que modificar el código de la aplicación. Por ejemplo, una aplicación de entrada de pedidos podría llamar al procedimiento InsertOrder con un número fijo de parámetros; exactamente cómo se implementa InsertOrder puede variar de una empresa a otra.
Reemplazabilidad Estrechamente relacionada con la colocación de reglas de negocio en procedimientos es el hecho de que los procedimientos se pueden reemplazar sin volver a compilar la aplicación. Si una regla de negocio cambia después de que una empresa haya comprado e instalado una aplicación, la empresa puede cambiar el procedimiento que contiene esa regla. Desde el punto de vista de la aplicación, nada ha cambiado; todavía llama a un procedimiento determinado para realizar una tarea determinada.
Los procedimientos SQL específicos de DBMS proporcionan una manera de que las aplicaciones aprovechen SQL específicos de DBMS y sigan siendo interoperables. Por ejemplo, un procedimiento en un DBMS que admite instrucciones de control de flujo en SQL podría interceptar y recuperarse de errores, mientras que un procedimiento en un DBMS que no admite instrucciones de control de flujo podría simplemente devolver un error.
Los procedimientos sobreviven a las transacciones En algunos orígenes de datos, los planes de acceso para todas las instrucciones preparadas de una conexión se eliminan cuando se confirma o revierte una transacción. Al colocar instrucciones SQL en procedimientos, que se almacenan permanentemente en el origen de datos, las instrucciones sobreviven a la transacción. Si los procedimientos sobreviven en un estado preparado, parcialmente preparado o no preparado depende del DBMS.
Desarrollo separado Los procedimientos pueden desarrollarse independientemente del resto de la aplicación. En grandes empresas, esto podría proporcionar una manera de aprovechar aún más las habilidades de los programadores altamente especializados. En otras palabras, los programadores de aplicaciones pueden escribir código de interfaz de usuario y programadores de bases de datos pueden escribir procedimientos.
Por lo general, las aplicaciones verticales y personalizadas usan procedimientos. Estas aplicaciones tienden a realizar tareas fijas y es posible codificar de forma rígida las llamadas a procedimientos en ellas. Por ejemplo, una aplicación de entrada de pedido podría llamar a los procedimientos InsertOrder, DeleteOrder, UpdateOrder y GetOrders.
No hay muchos motivos para llamar a procedimientos desde aplicaciones genéricas. Normalmente, los procedimientos se escriben para realizar una tarea en el contexto de una aplicación determinada, por lo que no tienen ningún uso para las aplicaciones genéricas. Por ejemplo, una hoja de cálculo no tiene ninguna razón para llamar al procedimiento InsertOrder que acabamos de mencionar. Además, las aplicaciones genéricas no deben construir procedimientos en tiempo de ejecución con la esperanza de proporcionar una ejecución de instrucciones más rápida; no solo es probable que sea más lento que la preparación o ejecución directa, sino que también requiere instrucciones SQL específicas de DBMS.
Una excepción a esto es entornos de desarrollo de aplicaciones, que a menudo proporcionan una manera de que los programadores compilen instrucciones SQL que ejecutan procedimientos y pueden proporcionar una manera para que los programadores prueben los procedimientos. Estos entornos llaman a SQLProcedures para enumerar procedimientos disponibles y SQLProcedureColumns para enumerar los parámetros de entrada, entrada/salida y salida, el valor devuelto del procedimiento y las columnas de los conjuntos de resultados creados por un procedimiento. Sin embargo, estos procedimientos deben desarrollarse de antemano en cada origen de datos; esto requiere instrucciones SQL específicas de DBMS.
Hay tres desventajas importantes para el uso de procedimientos. La primera es que los procedimientos deben escribirse y compilarse para cada DBMS con el que se va a ejecutar la aplicación. Aunque esto no es un problema para las aplicaciones personalizadas, puede aumentar significativamente el tiempo de desarrollo y mantenimiento de las aplicaciones verticales diseñadas para ejecutarse con una serie de DBMS.
La segunda desventaja es que muchos DBMS no admiten procedimientos. De nuevo, esto es más probable que sea un problema para las aplicaciones verticales diseñadas para ejecutarse con una serie de DBMS. Para determinar si se admiten procedimientos, una aplicación llama a SQLGetInfo con la opción SQL_PROCEDURES.
La tercera desventaja, que es especialmente aplicable a los entornos de desarrollo de aplicaciones, es que ODBC no define una gramática estándar para crear procedimientos. Es decir, aunque las aplicaciones pueden llamar a procedimientos de forma interoperable, no pueden crearlos de forma interoperable.