¿Qué es mejor?

Hola:
Cuando evaluas una alternativa de este tipo debes ponerla en contexto
con los objetivos de diseno, en este caso: Desempeno, Seguridad,
Matenimiento y Facilidad de Desesarrollo. Asumo que este codigo esta en un
Stored Procedure.
En Desempeno, es mas rapido el SELECT que el EXEC, la razon es que con
el EXEC no hay planes de ejecucion compilados previamente, entonces se tarda
mas. En algunas ocasiones el IF puede producir recompilaciones en cuyo caso
es mas lento pero se puede resolver haciendo SP's para cada SELECT.
Seguridad: El IF no requiere dar a los usuarios permisos sobre las
Tablas, el EXEC si. Adicionalmente es frecuente la "necesidad" de pasar
parametros a los SELECT en cuyo caso debe cuidarse uno de la inyeccion de
codigo.
Mantenimiento: Igual, siempre y cuando sea SQL 7/2000. Si deseas migrar
a otras bases de datos o incluso a nuevas versiones de SQL es posible que el
EXEC te de problemas. Adicionalmente es mas dificil/imposible depurar
EXEC's.
Facilidad de Desarrollo: Igual, si son sencillas. Cuando son mas
complejas suele ser mas facil hacerlo con EXEC.
En principio me alejaria del SQL Dinamico, es mucho mejor hacer esto
desde la aplicacion, si es necesario.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.


Naimps" <"@naimps@ <"@naimps@"@terra.es> escribio:

Buenas.

Qué es mejor:

IF (@x = 1)
SELECT ..
ELSE
SELECT ..

ó

IF (@x = 1)
set @SQL = 'select.'
ELSE
set @SQL = 'select.'

EXEC (@sql)

Recuerdo que álguien, en el foro, dijo que era mejor el EXEC porque
así el SQLServer no crea el plan de ejecución, o algo por el estilo.

Muchas gracias.

On Tue, 6 Apr 2004 05:20:14 -0600, Javier Loria wrote:

Hola:
Cuando evaluas una alternativa de este tipo debes ponerla en contexto
con los objetivos de diseno, en este caso: Desempeno, Seguridad,
Matenimiento y Facilidad de Desesarrollo. Asumo que este codigo esta en un
Stored Procedure.
En Desempeno, es mas rapido el SELECT que el EXEC, la razon es que con
el EXEC no hay planes de ejecucion compilados previamente, entonces se tarda
mas. En algunas ocasiones el IF puede producir recompilaciones en cuyo caso
es mas lento pero se puede resolver haciendo SP's para cada SELECT.
Seguridad: El IF no requiere dar a los usuarios permisos sobre las
Tablas, el EXEC si. Adicionalmente es frecuente la "necesidad" de pasar
parametros a los SELECT en cuyo caso debe cuidarse uno de la inyeccion de
codigo.
Mantenimiento: Igual, siempre y cuando sea SQL 7/2000. Si deseas migrar
a otras bases de datos o incluso a nuevas versiones de SQL es posible que el
EXEC te de problemas. Adicionalmente es mas dificil/imposible depurar
EXEC's.
Facilidad de Desarrollo: Igual, si son sencillas. Cuando son mas
complejas suele ser mas facil hacerlo con EXEC.
En principio me alejaria del SQL Dinamico, es mucho mejor hacer esto
desde la aplicacion, si es necesario.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.


Naimps" <"@naimps@ <"@naimps@"@terra.es> escribio:

Buenas.

Qué es mejor:

IF (@x = 1)
SELECT ..
ELSE
SELECT ..

ó

IF (@x = 1)
set @SQL = 'select.'
ELSE
set @SQL = 'select.'

EXEC (@sql)

Recuerdo que álguien, en el foro, dijo que era mejor el EXEC porque
así el SQLServer no crea el plan de ejecución, o algo por el estilo.

Muchas gracias.

Las consultas en las que pensaba utilizarlo son consultas con vaios
parámetros de búqueda.

Inicialmente utilizaba:
where (rep_tipo = @tipo) or (@tipo = 'Z'))
and ((rep_usuario = @usu) or (@usu = 0))
and ((rep_fecha = @fecha) or (@fecha = '1/1/2020'))

de esta forma, si el tipo daba igual, @tipo vale 'Z' y se cumple la
condición, y lo mismo para lo demás.

Mi idea era montar el select, y si da igual el tipo, pues no ponerlo.

Hola:
Este tipo de Where no le permite al SQL optimizar el plan de acceso de
forma adecuada o incluso mucho peor le produce el plan de acceso no
adecuado.
Si las tablas son pequenas (miles de filas, no cientos de miles de
filas) es muy probable que el impacto sea minimo o nulo. Podria ser incluso
que un Hint en la tabla sea lo mas recomendable para evitar el uso
incorrecto de los indices.
Si las tabla son medianas (cientos de miles de filas o millones de
filas) seria mejor que: lo resuelvas en la aplicacion (o sea que construyas
la consulta adecuada en el cliente) o que tengas una para cada caso facil si
son 3 opciones (8 consultas) dificil si son 5 (32 consultas).
Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

"Naimps" <"@naimps@"@terra.es> wrote in message
news:1ggz6y2dygtkb$.h0taaprly3j2$

On Tue, 6 Apr 2004 05:20:14 -0600, Javier Loria wrote:

> Hola:
> Cuando evaluas una alternativa de este tipo debes ponerla en

contexto

> con los objetivos de diseno, en este caso: Desempeno, Seguridad,
> Matenimiento y Facilidad de Desesarrollo. Asumo que este codigo esta en

un

> Stored Procedure.
> En Desempeno, es mas rapido el SELECT que el EXEC, la razon es que

con

> el EXEC no hay planes de ejecucion compilados previamente, entonces se

tarda

> mas. En algunas ocasiones el IF puede producir recompilaciones en cuyo

caso

> es mas lento pero se puede resolver haciendo SP's para cada SELECT.
> Seguridad: El IF no requiere dar a los usuarios permisos sobre las
> Tablas, el EXEC si. Adicionalmente es frecuente la "necesidad" de pasar
> parametros a los SELECT en cuyo caso debe cuidarse uno de la inyeccion

de

> codigo.
> Mantenimiento: Igual, siempre y cuando sea SQL 7/2000. Si deseas

migrar

> a otras bases de datos o incluso a nuevas versiones de SQL es posible

que el

> EXEC te de problemas. Adicionalmente es mas dificil/imposible depurar
> EXEC's.
> Facilidad de Desarrollo: Igual, si son sencillas. Cuando son mas
> complejas suele ser mas facil hacerlo con EXEC.
> En principio me alejaria del SQL Dinamico, es mucho mejor hacer esto
> desde la aplicacion, si es necesario.
> Saludos,
>
>
> Javier Loria
> Costa Rica
> Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
> que pueda ser copiado y pegado al Query Analizer.
> La version de SQL y Service Pack tambien ayuda.
>
>
> Naimps" <"@naimps@ <"@naimps@"@terra.es> escribio:
>> Buenas.
>>
>> Qué es mejor:
>>
>> IF (@x = 1)
>> SELECT ..
>> ELSE
>> SELECT ..
>>
>> ó
>>
>> IF (@x = 1)
>> set @SQL = 'select.'
>> ELSE
>> set @SQL = 'select.'
>>
>> EXEC (@sql)
>>
>> Recuerdo que álguien, en el foro, dijo que era mejor el EXEC porque
>> así el SQLServer no crea el plan de ejecución, o algo por el estilo.
>>
>> Muchas gracias.

Las consultas en las que pensaba utilizarlo son consultas con vaios
parámetros de búqueda.

Inicialmente utilizaba:
where (rep_tipo = @tipo) or (@tipo = 'Z'))
and ((rep_usuario = @usu) or (@usu = 0))
and ((rep_fecha = @fecha) or (@fecha = '1/1/2020'))

de esta forma, si el tipo daba igual, @tipo vale 'Z' y se cumple la
condición, y lo mismo para lo demás.

Mi idea era montar el select, y si da igual el tipo, pues no ponerlo.