SQL Dinamico

He puesto un ejemplo simple.

Si te fijas, el cod_mercado se filtra por >= y por <= porque a veces se pasa
y a veces no. Si se pasa, es el mismo valor para maximo que para minimo, por
eso los iguales, y si no se pasa, desde el cliente pongo el minimo = 0 y el
maximo = 100000 (un valor muy alto que nunca llegue). Es ajustar código en
servidor y en cliente.

Igualmente puedes hacer con cuantas columnas quieras, sin llegar al
infinito, obviamente.

Desde mi punto de vista, una where dinamica al 100% es una locura
dificilmente justificable. Es muy raro que un usuario lo necesite realmente.
La mayoría de las veces se usa sql dinámico por comodidad del programador,
velocidad de desarrollo, sin tener en cuenta las implicaciones en
redimiento, con lo cual se acaban necesitando superservidores.

Otro problerma aparte es el de nuestro colega Jano, porque si está haciendo
un generado de informes, no le queda mas remedio que usar sql dinámico. O
bien usar una aplicación ya hecha, como cristal report y semejantes, que
todos sabemos que usa sql dinámico.

Cada cosa para lo que es. El sql dinamico, para mi es la ultima opcion, pero
creo que Jano no tiene otra.

Saludos.


"Alejandro Mesa" escribió en el
mensaje news:

GenioMaestro,

mismas tablas, pero tengo WHERE dinámico por parámetros y orden dinámico
también por parámetros.

El filtro que usas no se considera dinamico en cuanto al numero de
columnas
que usa. Jano se refiere a que las columnas usadas en la clausula "where"
y/o
"order by" puede variar, y los parametros pueden venir con valores o con
valor "null".


AMB


"GenioMaestro" wrote:

Interesante, pero no lo recomiendo.

El SQL Dinamico es muy interesante porque te permite realizar la consulta
como quieras en cada momento, pero sp_executesql es muy lento en
comparación
con un procedimiento almacenado con parámetros.

Yo aconsejo trabajar un poco más y hacer algo como esto:

ALTER PROCEDURE [dbo].[VISOR_NOTAS](@F1 DATETIME, @MER_MIN AS INT,
@MER_MAX
AS INT, @ORDEN AS INT)
AS
SELECT TOP (1000) MERCADOS.Mercado, VALORES.Valor, VALORES.Descripcion,
COTIZACIONES.Cierre, CALCULOS.Fecha_Cal, CALCULOS.Momento140,
CALCULOS.Mom_Pen140, CALCULOS.Soporte, CALCULOS.Dif_Soporte,
CALCULOS.Resistencia, CALCULOS.Dif_Resistencia,
CALCULOS.Fecha_Resistencia, CALCULOS.Cap_Ponderada,
CALCULOS.Rango_Ponderado, CALCULOS.Etapa, CALCULOS.Calidad,
CALCULOS.Estado_Etapa, CALCULOS.Estado_Mv140, CALCULOS.Estado_Pen140,
CALCULOS.Nota_Rango, CALCULOS.Nota_Etapa,
CALCULOS.Nota_Estado, CALCULOS.Nota_Resistencia,
CALCULOS.Nota_Capitalizacion, CALCULOS.Nota_Precio, CALCULOS.NOTA_FINAL
FROM MERCADOS INNER JOIN
VALORES ON MERCADOS.Codigo = VALORES.Cod_Mercado INNER JOIN
COTIZACIONES ON VALORES.Auto_Cod_Valor = COTIZACIONES.Cod_Valor INNER
JOIN
CALCULOS ON COTIZACIONES.Cod_Valor = CALCULOS.Cod_Valor AND FECHA >> FECHA_CAL
WHERE
CALCULOS.Fecha_Cal = @F1 and
cod_mercado >= @MER_MIN and cod_mercado <= @MER_MAX
ORDER BY
CASE
WHEN @ORDEN = 1 then cast(Estado_Mv140 as char(10))
WHEN @ORDEN = 2 then calidad
WHEN @ORDEN = 3 then cast(Nota_Rango as char(10))
WHEN @ORDEN = 4 then cast(Nota_final as char(10))
END
DESC

La select es siempre la misma, siempre obtengo los mismos campos desde
las
mismas tablas, pero tengo WHERE dinámico por parámetros y orden dinámico
también por parámetros.

Es muy rápido, prácticamente instantáneo. Mira a ver si te vale.

Un saludo.



"Maxi [MVP]" escribió en el mensaje
news:eRKz%
> http://www.sommarskog.se/dyn-search.html
>
> Para leer
>
>
> Salu2
> -
> [MVP] SQL Server
> Orador para Culminis Latam
> www.sqlgurus.org
>
> MSN:
>
> "Jano" escribió en el mensaje
> news:
>> Compañeros
>>
>> En mi aplicacion los reportes pueden ser modificados en cuanto a la
>> cantidad de columnas que presenta, el filtro (where) y el orden (order
>> by). Investigando en la red, encontre que con SQL Dinamico puedo
>> solucionar el tema, pero por otro lado en muchos de los links que
>> investigue, hablaban de la inyeccion de codigo sql ( lo cual fue una
>> novedad para mi por ser novato en SQL Server) y me ha dejado
>> preocupado
>> este problema.
>>
>> Sobre el particular quisiera pedirles sus opiniones con respecto al
>> tema,
>> entiendo tambien que mucho de las soluciones se basan en las buenas
>> practicas de desarrollo con SQL Server. Como poder evitar la inyeccion
>> de
>> codigo SQL es la principal interrogante, como y cuando usar SQL
>> Dinamico,
>> que ese SQL Dinamico sea de optima ejecucion y otras cuestiones que
>> seguramente, colegas con mayor experiencia que yo, habran encontrando
>> en
>> su experiencia personal.
>>
>> Saludos
>>
>> Jano
>>
>
>

Eso creo yo tambien, he dado varias vueltas al asunto y segun la
funcionlidad que la aplicacion debe exponer, se necesita ese "dinamismo" en
los filtros y orders, aunque aun sigo investigando y buscando alternativas a
SQL Dinamico. Pero si aun y despues de todo, necesito continuar con SQL
Dinamico, me preocupa hacerlo de la forma mas segura y optima, por supuesto.
De ahi la razon de que haya iniciado este hilo.

Gracias colegas , sus opiniones me han dado mas luces sobre el tema. Reciban
un saludo cordial desde Lima - Peru





"GenioMaestro" wrote in message
news:e%

He puesto un ejemplo simple.

Si te fijas, el cod_mercado se filtra por >= y por <= porque a veces se
pasa y a veces no. Si se pasa, es el mismo valor para maximo que para
minimo, por eso los iguales, y si no se pasa, desde el cliente pongo el
minimo = 0 y el maximo = 100000 (un valor muy alto que nunca llegue). Es
ajustar código en servidor y en cliente.

Igualmente puedes hacer con cuantas columnas quieras, sin llegar al
infinito, obviamente.

Desde mi punto de vista, una where dinamica al 100% es una locura
dificilmente justificable. Es muy raro que un usuario lo necesite
realmente. La mayoría de las veces se usa sql dinámico por comodidad del
programador, velocidad de desarrollo, sin tener en cuenta las
implicaciones en redimiento, con lo cual se acaban necesitando
superservidores.

Otro problerma aparte es el de nuestro colega Jano, porque si está
haciendo un generado de informes, no le queda mas remedio que usar sql
dinámico. O bien usar una aplicación ya hecha, como cristal report y
semejantes, que todos sabemos que usa sql dinámico.

Cada cosa para lo que es. El sql dinamico, para mi es la ultima opcion,
pero creo que Jano no tiene otra.

Saludos.


"Alejandro Mesa" escribió en el
mensaje news:

GenioMaestro,

mismas tablas, pero tengo WHERE dinámico por parámetros y orden dinámico
también por parámetros.

El filtro que usas no se considera dinamico en cuanto al numero de
columnas
que usa. Jano se refiere a que las columnas usadas en la clausula "where"
y/o
"order by" puede variar, y los parametros pueden venir con valores o con
valor "null".


AMB


"GenioMaestro" wrote:

Interesante, pero no lo recomiendo.

El SQL Dinamico es muy interesante porque te permite realizar la
consulta
como quieras en cada momento, pero sp_executesql es muy lento en
comparación
con un procedimiento almacenado con parámetros.

Yo aconsejo trabajar un poco más y hacer algo como esto:

ALTER PROCEDURE [dbo].[VISOR_NOTAS](@F1 DATETIME, @MER_MIN AS INT,
@MER_MAX
AS INT, @ORDEN AS INT)
AS
SELECT TOP (1000) MERCADOS.Mercado, VALORES.Valor, VALORES.Descripcion,
COTIZACIONES.Cierre, CALCULOS.Fecha_Cal, CALCULOS.Momento140,
CALCULOS.Mom_Pen140, CALCULOS.Soporte, CALCULOS.Dif_Soporte,
CALCULOS.Resistencia, CALCULOS.Dif_Resistencia,
CALCULOS.Fecha_Resistencia, CALCULOS.Cap_Ponderada,
CALCULOS.Rango_Ponderado, CALCULOS.Etapa, CALCULOS.Calidad,
CALCULOS.Estado_Etapa, CALCULOS.Estado_Mv140,
CALCULOS.Estado_Pen140,
CALCULOS.Nota_Rango, CALCULOS.Nota_Etapa,
CALCULOS.Nota_Estado, CALCULOS.Nota_Resistencia,
CALCULOS.Nota_Capitalizacion, CALCULOS.Nota_Precio, CALCULOS.NOTA_FINAL
FROM MERCADOS INNER JOIN
VALORES ON MERCADOS.Codigo = VALORES.Cod_Mercado INNER JOIN
COTIZACIONES ON VALORES.Auto_Cod_Valor = COTIZACIONES.Cod_Valor
INNER
JOIN
CALCULOS ON COTIZACIONES.Cod_Valor = CALCULOS.Cod_Valor AND FECHA >>> FECHA_CAL
WHERE
CALCULOS.Fecha_Cal = @F1 and
cod_mercado >= @MER_MIN and cod_mercado <= @MER_MAX
ORDER BY
CASE
WHEN @ORDEN = 1 then cast(Estado_Mv140 as char(10))
WHEN @ORDEN = 2 then calidad
WHEN @ORDEN = 3 then cast(Nota_Rango as char(10))
WHEN @ORDEN = 4 then cast(Nota_final as char(10))
END
DESC

La select es siempre la misma, siempre obtengo los mismos campos desde
las
mismas tablas, pero tengo WHERE dinámico por parámetros y orden dinámico
también por parámetros.

Es muy rápido, prácticamente instantáneo. Mira a ver si te vale.

Un saludo.



"Maxi [MVP]" escribió en el mensaje
news:eRKz%
> http://www.sommarskog.se/dyn-search.html
>
> Para leer
>
>
> Salu2
> -
> [MVP] SQL Server
> Orador para Culminis Latam
> www.sqlgurus.org
>
> MSN:
>
> "Jano" escribió en el mensaje
> news:
>> Compañeros
>>
>> En mi aplicacion los reportes pueden ser modificados en cuanto a la
>> cantidad de columnas que presenta, el filtro (where) y el orden
>> (order
>> by). Investigando en la red, encontre que con SQL Dinamico puedo
>> solucionar el tema, pero por otro lado en muchos de los links que
>> investigue, hablaban de la inyeccion de codigo sql ( lo cual fue una
>> novedad para mi por ser novato en SQL Server) y me ha dejado
>> preocupado
>> este problema.
>>
>> Sobre el particular quisiera pedirles sus opiniones con respecto al
>> tema,
>> entiendo tambien que mucho de las soluciones se basan en las buenas
>> practicas de desarrollo con SQL Server. Como poder evitar la
>> inyeccion de
>> codigo SQL es la principal interrogante, como y cuando usar SQL
>> Dinamico,
>> que ese SQL Dinamico sea de optima ejecucion y otras cuestiones que
>> seguramente, colegas con mayor experiencia que yo, habran encontrando
>> en
>> su experiencia personal.
>>
>> Saludos
>>
>> Jano
>>
>
>

En realidad, es muy buena practica usar SP's, sin embargo el argumento en
velocidad de ejecucion no es valido para este caso, pues el tiempo de
ejecucion es el mismo, lo unico que te ahorras es el plan de ejecucion, que
por cierto no he podido apreciarlo, supongo que con cualquier procesador de
mas de 1 Ghz llega a ser imperceptible y no medio segundo como indica el
articulo.

Por otro lado el argumento del trafico en red, podria ser posible si tu
consulta mide varios Kb's y se ejecuta cientos o miles de veces en poco
tiempo. En mi experiencia tengo una aplicacion donde todas las consultas son
SQL Dinamico, incluso algunas muy complejas con mas de una docena de
relaciones y el resultado se muestra en no mas de 2 o 3 segs. Esto llego a
ser a si, por mi poco dominio de SQL Server en ese entonces.

En todo caso la seguridad y claridad de tu codigo en la aplicacion deberian
ser argumentos suficientes para que en lo posible evites SQL dinamico.


saludos,


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com



"Jano" escribió en el mensaje
news:O0WG2$

Eso creo yo tambien, he dado varias vueltas al asunto y segun la
funcionlidad que la aplicacion debe exponer, se necesita ese "dinamismo"
en los filtros y orders, aunque aun sigo investigando y buscando
alternativas a SQL Dinamico. Pero si aun y despues de todo, necesito
continuar con SQL Dinamico, me preocupa hacerlo de la forma mas segura y
optima, por supuesto. De ahi la razon de que haya iniciado este hilo.

Gracias colegas , sus opiniones me han dado mas luces sobre el tema.
Reciban un saludo cordial desde Lima - Peru





"GenioMaestro" wrote in message
news:e%

He puesto un ejemplo simple.

Si te fijas, el cod_mercado se filtra por >= y por <= porque a veces se
pasa y a veces no. Si se pasa, es el mismo valor para maximo que para
minimo, por eso los iguales, y si no se pasa, desde el cliente pongo el
minimo = 0 y el maximo = 100000 (un valor muy alto que nunca llegue). Es
ajustar código en servidor y en cliente.

Igualmente puedes hacer con cuantas columnas quieras, sin llegar al
infinito, obviamente.

Desde mi punto de vista, una where dinamica al 100% es una locura
dificilmente justificable. Es muy raro que un usuario lo necesite
realmente. La mayoría de las veces se usa sql dinámico por comodidad del
programador, velocidad de desarrollo, sin tener en cuenta las
implicaciones en redimiento, con lo cual se acaban necesitando
superservidores.

Otro problerma aparte es el de nuestro colega Jano, porque si está
haciendo un generado de informes, no le queda mas remedio que usar sql
dinámico. O bien usar una aplicación ya hecha, como cristal report y
semejantes, que todos sabemos que usa sql dinámico.

Cada cosa para lo que es. El sql dinamico, para mi es la ultima opcion,
pero creo que Jano no tiene otra.

Saludos.


"Alejandro Mesa" escribió en el
mensaje news:

GenioMaestro,

mismas tablas, pero tengo WHERE dinámico por parámetros y orden
dinámico
también por parámetros.

El filtro que usas no se considera dinamico en cuanto al numero de
columnas
que usa. Jano se refiere a que las columnas usadas en la clausula
"where" y/o
"order by" puede variar, y los parametros pueden venir con valores o con
valor "null".


AMB


"GenioMaestro" wrote:

Interesante, pero no lo recomiendo.

El SQL Dinamico es muy interesante porque te permite realizar la
consulta
como quieras en cada momento, pero sp_executesql es muy lento en
comparación
con un procedimiento almacenado con parámetros.

Yo aconsejo trabajar un poco más y hacer algo como esto:

ALTER PROCEDURE [dbo].[VISOR_NOTAS](@F1 DATETIME, @MER_MIN AS INT,
@MER_MAX
AS INT, @ORDEN AS INT)
AS
SELECT TOP (1000) MERCADOS.Mercado, VALORES.Valor, VALORES.Descripcion,
COTIZACIONES.Cierre, CALCULOS.Fecha_Cal, CALCULOS.Momento140,
CALCULOS.Mom_Pen140, CALCULOS.Soporte, CALCULOS.Dif_Soporte,
CALCULOS.Resistencia, CALCULOS.Dif_Resistencia,
CALCULOS.Fecha_Resistencia, CALCULOS.Cap_Ponderada,
CALCULOS.Rango_Ponderado, CALCULOS.Etapa, CALCULOS.Calidad,
CALCULOS.Estado_Etapa, CALCULOS.Estado_Mv140,
CALCULOS.Estado_Pen140,
CALCULOS.Nota_Rango, CALCULOS.Nota_Etapa,
CALCULOS.Nota_Estado, CALCULOS.Nota_Resistencia,
CALCULOS.Nota_Capitalizacion, CALCULOS.Nota_Precio, CALCULOS.NOTA_FINAL
FROM MERCADOS INNER JOIN
VALORES ON MERCADOS.Codigo = VALORES.Cod_Mercado INNER JOIN
COTIZACIONES ON VALORES.Auto_Cod_Valor = COTIZACIONES.Cod_Valor
INNER
JOIN
CALCULOS ON COTIZACIONES.Cod_Valor = CALCULOS.Cod_Valor AND FECHA >>>> FECHA_CAL
WHERE
CALCULOS.Fecha_Cal = @F1 and
cod_mercado >= @MER_MIN and cod_mercado <= @MER_MAX
ORDER BY
CASE
WHEN @ORDEN = 1 then cast(Estado_Mv140 as char(10))
WHEN @ORDEN = 2 then calidad
WHEN @ORDEN = 3 then cast(Nota_Rango as char(10))
WHEN @ORDEN = 4 then cast(Nota_final as char(10))
END
DESC

La select es siempre la misma, siempre obtengo los mismos campos desde
las
mismas tablas, pero tengo WHERE dinámico por parámetros y orden
dinámico
también por parámetros.

Es muy rápido, prácticamente instantáneo. Mira a ver si te vale.

Un saludo.



"Maxi [MVP]" escribió en el mensaje
news:eRKz%
> http://www.sommarskog.se/dyn-search.html
>
> Para leer
>
>
> Salu2
> -
> [MVP] SQL Server
> Orador para Culminis Latam
> www.sqlgurus.org
>
> MSN:
>
> "Jano" escribió en el mensaje
> news:
>> Compañeros
>>
>> En mi aplicacion los reportes pueden ser modificados en cuanto a la
>> cantidad de columnas que presenta, el filtro (where) y el orden
>> (order
>> by). Investigando en la red, encontre que con SQL Dinamico puedo
>> solucionar el tema, pero por otro lado en muchos de los links que
>> investigue, hablaban de la inyeccion de codigo sql ( lo cual fue una
>> novedad para mi por ser novato en SQL Server) y me ha dejado
>> preocupado
>> este problema.
>>
>> Sobre el particular quisiera pedirles sus opiniones con respecto al
>> tema,
>> entiendo tambien que mucho de las soluciones se basan en las buenas
>> practicas de desarrollo con SQL Server. Como poder evitar la
>> inyeccion de
>> codigo SQL es la principal interrogante, como y cuando usar SQL
>> Dinamico,
>> que ese SQL Dinamico sea de optima ejecucion y otras cuestiones que
>> seguramente, colegas con mayor experiencia que yo, habran
>> encontrando en
>> su experiencia personal.
>>
>> Saludos
>>
>> Jano
>>
>
>