Proced. Almacenados Vs. Consultas SQL

Yo sabes lo que hacía según algún libro, para que el optimizador siempre
acierte sin necesidad del recompile, pues tenía un procedimiento almacenado
que hacía lo siguiente

CREATE PROC spConsultarDatos
@FechaInicio datetime,
@FechaFin datetime
AS
BEGIN
IF DATEPART(mm,@FechaFin)-DATEPART(mm,@FechaInicio) <= 3
EXEC spConsultarDatosRangoMin @FechaInicio, @FechaFin
ELSE
EXEC spConsultarDatosRangoMax @FechaInicio, @FechaFin
END

De esta manera, consigues que las peticiones con unos intervalos de fechas
vayan por un sitio y el resto por otro.

De todas maneras todos estamos de acuerdo, en que los programas no son
inteligentes, de manera que hay que 'ayudarles' en cierta forma.

Salu2

"Pedro Luna Montalvo" wrote in message
news:

> 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 pla

n

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.
> >
> >
>
>