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

Ante todo, hola a

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

estoy en un punto muerto. Se que lo he pedido en otras

muy liado: es en relación a los Stored Procedure (SP)

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

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

parámetros PA, se pueden ejecutar 4 consultas distintas;

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

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

parámetros vale 0, no lo pngo en el WHERE).

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

diferentes, el SQLServer tiene cada vez que generar el

se pierde tiempo. Poco, pero se pierde tiempo. Y que con

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

verdad?

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

las dejo todas en el mismo SP?

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

TRAN. LO hago para poder deshacer las transacciones si

necesito bloquear una tabla. Se me ha ocurrido relizar el

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

pero justo antes poner SET TRANSACTION ISOLATION LEVEL

después del UPDATE dejar el predeterminado 8SET

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

Bastante liado, ¿verdad?

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?

Hola Ulises.

Ya me han recomendado ese artículo, pero está en inglés y

tarea de traducirlo.

Ya se que el BEGIN TRAN justo cuanto más tarde y el

posible, pero en este caso lo hago para que si por en

el SQLServer realize el ROLLBACK.

Y lo de poner SET TRANSACTION ISOLATION LEVEL, es porque

como es un contador de facturas, necesito que cuando el

nadie tenga acceso para evitar datos incongruentes;

dentro del BEGIN TRAN quedaba bloqueada, pero me dijeron

Me dices de separar las sentencias en SP para que sea más

mantenimiento, pero ¿y a nivel de rendimiento?

Muchas gracias por responder.
.