Proced. Almacenados Vs. Consultas SQL

A nivel de rendimiento siempre son mejores los
procedimientos almacenados.
Además piensa que cuando utilizas un procedimiento
almacenado los datos sobre los que accede dicho
procedimiento no necesitan salir del servidor de BBDD...
Imaginate tener que realizar cierto calculo con un millon
de registros... Si no usaras un procedimiento almacenado
el millón de registros deberían circular por la red des
del servidor de BBDD hasta la máquina que ejecutase la
consulta SQL...

Edu

Quisiera discutir un poco sobre qué es mejor utilizar,

Si procedimientos

almcenados o consultas SQL normales; ya que he escuchado

que en .NET los

procedimientos almacenados tienen menor rendimiento.


.

Saludos:

Pues si tienes referencia de donde escuchaste eso, me gustaria oir mas sobre
su opinion.
Por mi lado, mi opinion es completamente la contraria, y te expongo causas.

Cuando se "compila" un procedimiento almacenado en la base de datos, el
optimizador del motor determina en ese momento el plan de ejecucion del
mismo, es decir, que indices deberia utilizar, la secuencia de operaciones
para ejecutar consultas complejas, etc, etc.

Esta informacion se guarda junto con el procedimiento, de forma que cuando
el usuario lo invoque, esta informacion sirva para una rapida y eficiente
ejecucion del mismo. Esto ocurre solamente una sola vez, cuando se crea o
modifica el procedimiento.

Por otro lado, si lo que pasas al motor son sentencias a manera de texto
plano, cada vez que se ejecute y por cada usuario, se debera analizar la
sintaxis del comando, evaluar el plan de ejecucion, escoger indices, etc,
etc. Esto por cada invocacion que se haga a esta sentencia.

Pongamos una aplicacion donde (seamos "buen dato" como decimos por aca),
solamente 25 usuarios ejecutan una operacion intensivamente.

Cual crees que le costaria menor esfuerzo al servidor de datos?
Cual crees que respondera y ejecutara mas rapidamente?

Saludos
Pedro Luna, MVP
Gye, Ecu

"David SC" escribió en el mensaje
news:

Quisiera discutir un poco sobre qué es mejor utilizar, Si procedimientos
almcenados o consultas SQL normales; ya que he escuchado que en .NET los
procedimientos almacenados tienen menor rendimiento.

"Pedro Luna Montalvo" escribió en el mensaje
news:etg%

Saludos:

Pues si tienes referencia de donde escuchaste eso, me gustaria oir mas

sobre

su opinion.
Por mi lado, mi opinion es completamente la contraria, y te expongo

causas.

Cuando se "compila" un procedimiento almacenado en la base de datos, el
optimizador del motor determina en ese momento el plan de ejecucion del
mismo, es decir, que indices deberia utilizar, la secuencia de operaciones
para ejecutar consultas complejas, etc, etc.

Esta informacion se guarda junto con el procedimiento, de forma que cuando
el usuario lo invoque, esta informacion sirva para una rapida y eficiente
ejecucion del mismo. Esto ocurre solamente una sola vez, cuando se crea o
modifica el procedimiento.

Interesante. Si el plan se evalúa cuando se compila el procedimento,
entonces, si después se agrega a la base de datos un índice que aceleraría
muchas de las consultas previamente compiladas, ¿es necesario volver a
compilar cada procedimiento para aprovechar el nuevo índice?

Saludos,

-Jorge

Por definición, siempre mejor los Procedimientos Almacenados, siempre que
vaya acompañado por un buen conocimiento de TransactSQL y que se sepa como
optimizarlos. Detodas maneras, no tiene nada que ver con .NET.

Yo lo tengo claro por las siguientes cosas:
1.- Ya está compilado el arbol de ejecución y analizada la sentencia, luego
el SQL Server se ahorra el trabajo de analizar la sintaxis del SQL y ver su
plan de ejecución.
2.- Los parámetros que se le pasan ya definen el tipo de variable, lo que es
mejor para que el optimizador seleccione los SARG'S más adecuados
3.- Los parámetros de texto, presentan menos problemas, ya que sino tienes
que estar pendientes con las comillas simples, dobles, etc.
4.- Se pueden crear cursores de servidor, de manera que el tráfico de datos
se reduzca
5.- Un cambio en el procedimiento almacenado no conlleva un cambio de la
aplicación que los usa
6.- Al actualizar la versión del SQL o migrar la aplicación se sabe en
concreto que recursos de la base de datos se están usando, de la otra manera
al ser dinámicos esto resulta imposible sin volver a probar toda la
aplicación

Reconozco que también tienen sus pegas, sobre todo en sistemas con muchos
usuarios donde hay que tener cuidado con las continuas recompilaciones de
los procedimientos almacenados, etc...pero eso buscando información se
pueden crear bien.

Sobre el tema del conocimiento del transact, es por determinados
comportamientos del optimizador.. por ejemplo algo que le pasa a la gente
muy a menudo:
1-- Tienes un procedimiento almacenado con una fecha desde y otra hasta
2-- La primera llamada la pide un usuario para recuperar datos de un mes
3-- El compilador crea un plan de ejecución y decide utilizar un indice para
recuperar la información
4-- Acto seguido otro usuario pide el mismo procedimiento pero con un
intervalo enorme de fechas, como ya hay un plan se ejecuta con dicho plan.
Sin embargo, si hubieramos hecho esta llamada la primera, seguramente el
optimizador habría preferido realizar un table scan, por el gran número de
filas que se devuelven y esto hubiera sido más óptimo. Pero para todo hay
trucos depende del grado de optimización que quieras reflejar.

Mi consejo, usar procedimientos almacenados e investiga todo lo que puedas
la información de rendimiento y trucos de optimización, ya verás como te irá
fenomenal.

Salu2

"David SC" wrote in message
news:

Quisiera discutir un poco sobre qué es mejor utilizar, Si procedimientos
almcenados o consultas SQL normales; ya que he escuchado que en .NET los
procedimientos almacenados tienen menor rendimiento.

1-- Tienes un procedimiento almacenado con una fecha desde y otra hasta
2-- La primera llamada la pide un usuario para recuperar datos de un mes
3-- El compilador crea un plan de ejecución y decide utilizar un indice

para

recuperar la información
4-- Acto seguido otro usuario pide el mismo procedimiento pero con un
intervalo enorme de fechas, como ya hay un plan se ejecuta con dicho plan.
Sin embargo, si hubieramos hecho esta llamada la primera, seguramente el
optimizador habría preferido realizar un table scan, por el gran número de
filas que se devuelven y esto hubiera sido más óptimo. Pero para todo hay
trucos depende del grado de optimización que quieras reflejar.

Saludos Lazaro,


Muy importante tus observaciones y oportunas a la vez. Solo queria agregar
algo mas, para consultas como la que mencionas, en las cuales segun los
parametros del procedimiento u otro dato variable, el plan de ejecucion
puede verse afectado constantemente, es mejor usar la clausula WITH
RECOMPILE del procedimiento, para que el optimizador siempre decida el plan
de ejecucion.

Saludos
Pedro Luna, MVP
Gye, Ecu


"Lázaro" escribió en el mensaje
news:

Por definición, siempre mejor los Procedimientos Almacenados, siempre que
vaya acompañado por un buen conocimiento de TransactSQL y que se sepa como
optimizarlos. Detodas maneras, no tiene nada que ver con .NET.

Yo lo tengo claro por las siguientes cosas:
1.- Ya está compilado el arbol de ejecución y analizada la sentencia,

luego

el SQL Server se ahorra el trabajo de analizar la sintaxis del SQL y ver

su

plan de ejecución.
2.- Los parámetros que se le pasan ya definen el tipo de variable, lo que

es

mejor para que el optimizador seleccione los SARG'S más adecuados
3.- Los parámetros de texto, presentan menos problemas, ya que sino tienes
que estar pendientes con las comillas simples, dobles, etc.
4.- Se pueden crear cursores de servidor, de manera que el tráfico de

datos

se reduzca
5.- Un cambio en el procedimiento almacenado no conlleva un cambio de la
aplicación que los usa
6.- Al actualizar la versión del SQL o migrar la aplicación se sabe en
concreto que recursos de la base de datos se están usando, de la otra

manera

al ser dinámicos esto resulta imposible sin volver a probar toda la
aplicación

Reconozco que también tienen sus pegas, sobre todo en sistemas con muchos
usuarios donde hay que tener cuidado con las continuas recompilaciones de
los procedimientos almacenados, etc...pero eso buscando información se
pueden crear bien.

Sobre el tema del conocimiento del transact, es por determinados
comportamientos del optimizador.. por ejemplo algo que le pasa a la gente
muy a menudo:
1-- Tienes un procedimiento almacenado con una fecha desde y otra hasta
2-- La primera llamada la pide un usuario para recuperar datos de un mes
3-- El compilador crea un plan de ejecución y decide utilizar un indice

para

recuperar la información
4-- Acto seguido otro usuario pide el mismo procedimiento pero con un
intervalo enorme de fechas, como ya hay un plan se ejecuta con dicho plan.
Sin embargo, si hubieramos hecho esta llamada la primera, seguramente el
optimizador habría preferido realizar un table scan, por el gran número de
filas que se devuelven y esto hubiera sido más óptimo. Pero para todo hay
trucos depende del grado de optimización que quieras reflejar.

Mi consejo, usar procedimientos almacenados e investiga todo lo que puedas
la información de rendimiento y trucos de optimización, ya verás como te

irá

fenomenal.

Salu2

"David SC" wrote in message
news:
> Quisiera discutir un poco sobre qué es mejor utilizar, Si procedimientos
> almcenados o consultas SQL normales; ya que he escuchado que en .NET los
> procedimientos almacenados tienen menor rendimiento.
>
>