Dudas sore SP, sql dinámico y un de bloqueos.

28/04/2004 - 20:11 por Víctor | Informe spam
Ante todo, hola a tod@s.

No se si es pedir mucho, pero me gustaría que me aclaren unas dudas, porque
estoy en un punto muerto. Se que lo he pedido en otras ocasiones, pero estoy
muy liado: es en relación a los Stored Procedure (SP) junto con consultas
estáticas, consultas dinámicas y planes de ejecución.

Caso práctico: tengo un SP con varios parámetros de entrada. Según dos
parámetros PA, se pueden ejecutar 4 consultas distintas; los otros
parámetros PW son variables para la cláusula WHERE de las consultas.

IF
consulta = consulta 1
ELSE IF
consulta = consulta 2
ELSE IF
consulta = consulta 3
ELSE
consulta = consulta 4
EXEC (consulta)

Dentro de cada IF monto el WHERE según las parámetros PW (pues si un
parámetros vale 0, no lo pngo en el WHERE).

Uso las consultas dinámicas porque hace tiempo lei que si las consultas son
diferentes, el SQLServer tiene cada vez que generar el plan de ejecución, y
se pierde tiempo. Poco, pero se pierde tiempo. Y que con las consultas
dinámicas no lo crea (cosa que ahora mismo me parece raro, ¿no?). ¿Es
verdad?

Si es mejor no hacer el SELECT dinámico, ¿creo un SP para cada consulta o
las dejo todas en el mismo SP?

Una última cosa. En un SP empiezo con un BEGIN TRAN y termino con el COMMIT
TRAN. LO hago para poder deshacer las transacciones si ocurre algo, pero
necesito bloquear una tabla. Se me ha ocurrido relizar el SELECT de la tabla
y luego su UPDATE lo último de todo (pero siempre dentro del BEGIN/COMMIT),
pero justo antes poner SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, y
después del UPDATE dejar el predeterminado 8SET TRANSACTION ISOLATION LEVEL
READ UNCOMMITTED, creo que es). ¿Funcionará?

Bastante liado, ¿verdad?
 

Leer las respuestas

#1 ulises
28/04/2004 - 20:36 | Informe spam
1) En primer lugar te paso una lectura obligada sobre SQL
dinámico :

The Curse and Blessings of Dynamic SQL
http://www.algonet.se/~sommar/dynamic_sql.html

2) En el procedimiento almacenado, si las sentencias son
muy complejas yo las separaría en procedimientos
almacenados independientes para efectos de facilitar su
mantenimiento.

3) Trata de colocar el BEGIN TRAN lo más tarde que puedas
(no al inicio del procedimiento almacenado) y el COMMIT
TRAN (o ROLLBACK) lo más pronto de manera de tratar de
minizar que los bloqueos asimismo yo dejaría que el SQL
maneje los bloqueos.

Saludos,
Ulises

Ante todo, hola a

No se si es pedir mucho, pero me gustaría que me aclaren


unas dudas, porque
estoy en un punto muerto. Se que lo he pedido en otras


ocasiones, pero estoy
muy liado: es en relación a los Stored Procedure (SP)


junto con consultas
estáticas, consultas dinámicas y planes de ejecución.

Caso práctico: tengo un SP con varios parámetros de


entrada. Según dos
parámetros PA, se pueden ejecutar 4 consultas distintas;


los otros
parámetros PW son variables para la cláusula WHERE de las


consultas.

IF
consulta = consulta 1
ELSE IF
consulta = consulta 2
ELSE IF
consulta = consulta 3
ELSE
consulta = consulta 4
EXEC (consulta)

Dentro de cada IF monto el WHERE según las parámetros PW


(pues si un
parámetros vale 0, no lo pngo en el WHERE).

Uso las consultas dinámicas porque hace tiempo lei que si


las consultas son
diferentes, el SQLServer tiene cada vez que generar el


plan de ejecución, y
se pierde tiempo. Poco, pero se pierde tiempo. Y que con


las consultas
dinámicas no lo crea (cosa que ahora mismo me parece


raro, ¿no?). ¿Es
verdad?

Si es mejor no hacer el SELECT dinámico, ¿creo un SP para


cada consulta o
las dejo todas en el mismo SP?

Una última cosa. En un SP empiezo con un BEGIN TRAN y


termino con el COMMIT
TRAN. LO hago para poder deshacer las transacciones si


ocurre algo, pero
necesito bloquear una tabla. Se me ha ocurrido relizar el


SELECT de la tabla
y luego su UPDATE lo último de todo (pero siempre dentro


del BEGIN/COMMIT),
pero justo antes poner SET TRANSACTION ISOLATION LEVEL


SERIALIZABLE, y
después del UPDATE dejar el predeterminado 8SET


TRANSACTION ISOLATION LEVEL
READ UNCOMMITTED, creo que es). ¿Funcionará?

Bastante liado, ¿verdad?

Preguntas similares