Procedimientos Almacenados Temporales

Esto puede sonar algo extraño, ya que lo común es hablar de tablas temporales, sin embargo, también existen procedimientos almacenados temporales, sí, estos al igual que las tablas temporales tienen como ambito de vida la sesión que los creó. En este post discutiremos cómo crearlos y porqué crearlos.

Para crear los procedimientos almacenados temporales, se debe simplemente colocar un numeral “#” antes del nombre. Por ejemplo el siguiente código creará un procedimiento almacenado temporal local que obtendrá la lista de tablas más el número de columnas.

CREATE PROCEDURE #spu_ObtenerTablasColumnas
AS
SELECT t.TABLE_SCHEMA, t.TABLE_NAME, COUNT(1) AS NUMERO_COLUMNAS
FROM INFORMATION_SCHEMA.TABLES t
INNER JOIN INFORMATION_SCHEMA.COLUMNS c
on t.TABLE_SCHEMA = c.TABLE_SCHEMA
and t.TABLE_NAME = c.TABLE_NAME
GROUP BY t.TABLE_SCHEMA, t.TABLE_NAME
ORDER BY 1,2

2018-08-22 18_07_13

Luego de creado el procedimiento almacenado temporal, éste se puede ejecutar, pero solo dentro de la misma sesión que lo creó, no puede ser llamado desde otra sesión, a menos que el procedimiento almacenado temporal se creé de forma global, es decir, en vez de agregar un símbolo de numeral #, se agregue dos símbolos de numeral ##, de esta forma el procedimiento almacenado puede ser llamado desde cualquier sesión, siempre y cuando la sesión que lo creo se mantenga conectada, es decir tiene el mismo comportamiento que las tablas temporales globales.

Ahora, ¿por qué es necesaria la utilización de procedimientos almacenados temporales? A mi parecer la principal razón para su utilización es el querer probar alguna modificación en un procedimiento almacenado normal sin tocar el código de éste, entonces crearíamos este procedimiento almacenado temporal con los cambios requeridos y probaríamos su funcionamiento con la misma data que el procedimiento almacenado normal.

Es importante mencionar que para crear los procedimientos almacenados temporables no necesitamos tener permisos especiales sobre la base de datos sobre la que los crearemos, lo cual evita tener problemas de permisos para probar dichos cambios.

Algunos preguntarían por qué no simplemente probar el código del procedimiento almacenado directamente sobre la base de datos, y utilizar variables en vez de parámetros, y si bien es cierto, funcionalmente esto es posible, los resultados que se obtendrán no serán reales, ya que cuando usamos procedimientos almacenados, los valores de los párametros si son conocidos al momento de compilar el código y por ende, SQL Server optimizará el plan de ejecución para esos valores, mientras que si solamente utilizamos variables, estas no permiten a SQL Server saber que valores vienen en tiempo de ejecución, y  SQL Server tendra que crear un plan de ejecución basado en las estadisticas generales de las tablas, las cuales pueden estar o no  correctas.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Google photo

Estás comentando usando tu cuenta de Google. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s