Procedimientos Almacenados contra consultas

Actualizado el día 03/03/2009.

Hoy toca hablar de las ventajas de usar procedimientos almacenados en Microsoft SQL 7/2000/2005/2008 contra las desventajas de hacer las mismas consultas desde el Objeto Connection o Command de Visual Basic 6.0 (aplicable a otros lenguajes de programación como .NET).

Cada vez que lanzamos una consulta contra SQLServer, éste tiene que calcular las estadísticas de ejecución para comprobar cual va a ser el mejor método y más rápido de la consulta a no ser que tenga ya unas almacenadas, y así, conseguir que los resultados aparezcan en el menor tiempo posible, por eso es vital que la consulta se igual en su semántica para no tener que recalcularlas cada vez que lanzamos la consulta. Por eso pienso y es mi opinión particular y entendida despues de algunas nociones y consejos de colegas de profesión y algún que otro SUMMIT que podríamos ahorrar un poco de tiempo al lanzar nuestras consultas si éstas las encapsulamos en procedimientos almacenados.

Como iba diciendo, SQL guarda estas estadísticas en la caché, de disco o memoria, además de los datos consultados por si se vuelve a repretir la operación. (De aquí he llegado a la conclusión de que el consumo desmesurado de la memoria caché hace que la memoria de nuestro servidor SQL esté siempre a tope y por eso me gusta contralarla en las propiedades del servidor SQL.)

Ahora bien, he recomendado usar procedimientos almacenados, ¿pasa si trabajamos con un procedimiento almacenado(SP)? Cuando creamos un SP, este genera unas estadísticas de consulta que guarda para el SP creado. En el caso que desde nuestro programa haga una consulta contra ese procedimiento ya tiene las estadísticas creadas, por lo que se ahorra un tiempo precioso para nuestro servidor, además de recursos si en vez de eso le mandamos consultas dinámicas del tipo select, creadas con nuestro programa VB6 ó NET y que tiene 20 parámetros en el where cada uno distinto al otro y con mil maneras de ordenar los resultados.

Mención aparte de que hay que tener cuidado aquí con el nombre del SP y con la llamada a ese SP, para SQL Server AAA y aaa no es lo mismo aunque luego llame al SP AAA. Es decir que si tenemos AAA como SP y llamamos a aaa, el SP se ejecutará bien, pero habrá vuelto a crear las estadísticas para este SP o no?, pues puede que sí, porque como las busque en memoria lo más probable es que no las encuentre.

Pensar que una aplicación como la que hemos desarrollado en la empresa en la que trabajo, puede hacer unas 5-10 consultas contra la bd por minuto y por puesto. La aplicación corre en despachos que van desde un puesto hasta 60, imaginar cuanto tiempo estamos ahorrando siguiendo este sistema de procedimientos almacenados y lo estructurados que nos quedan los programas llamando todos a los mismos P.A.

Por último, debemos tener en cuenta que la base de datos puede crecer y que quizás en algún momento de la vida de aplicación deberíamos revisar las estadísticas y los índices de la base de datos, para comprobar que estas trabajan realmente bien, no viene mal chequear el rendimiento de aquellos procedimientos almacenados que se han cambiado a lo largo del tiempo. ¿Imaginas que un índice para una tabla no te sirviera si la tabla crece a más de 1 millón de registros y que todas las consultas a esa table se caen en rendimiento?.

El punto anterior lo dice todo, si tuvieramos intrucciones SQL en nuestro código, tendríamos que revisar todos nuestros programitas y volvernos locos porque seguro que habría consultas de aquel que se fué hace 2 años y que no ponía comentarios en su código. Si tenemos P.A. tan sólo hay que buscar los objetos dependientes de esa tabla maldita y arreglarlos desde el mismo management studio, mucho menos tiempo que recorrer ingentes cantidades de código de programas olvidados en el recuerdo de algunos que ya no están.

Unas nomenclaturas fáciles para los P.A podrían ser las siguientes para una tabla de CLIENTES:

Clientes_Leer_Uno
Clientes_Leer_Lista
Clientes_Insertar
Clientes_Actualizar
Clientes_Borrar
Clientes_Listar_Por_Apellidos
Clientes_Listar_Pendientes

etc....

No es parece más fácil?, además tanto reporting como crystal soportan procedimientos almacenados, así que en un mantenimiento no previsto dónde un resultado de listado fuera complejo, se podría estructurar de una manera fácil dónde nuestro gestor de informes no sufriera un cambio radical o ninguno por el cambio de nombre de la fuente de datos ¿no os ha pasado que una vez que utilizas una vista compleja en un par de listados, resulta que un día uno de los listados ya no nos sirve y nos toca hacer una vista nueva que crystal reports omite porque no se llama igual que la anterior y toca rehacer el listado?.

Pues eso: Report_Pendientes_de_Cobro lee del SP Contabilidad_Pendienes_De_Cobro siempre, usemos una vista u otra.