Últimos mensajes - Powered by IBM

Palabras claves

Otro debate (mas) sobre los Procedimientos Almacenados

28/04/2008 - 14:00 por Pablo Roca | Informe spam

Siento si el tema es recurrente, pero ahi va:

El siguiente hilo es para proponer un debate (amistoso) sobre los
procedimientos almacenados.

Llegué hace poco a SQL Server 2005 y de lo primero que hice fué empezar a
programar todo o casi todo con procedimientos almacenados. Hasta aquí bien,
en momentos noté que (a ratos) las consultas no iban todo lo bien que
debieran ...

Soy un cliente final, y mi casuistica particular me impone que tenga que
utilizar unas 60 bases de datos. Por lo que uno piensa en buscarse la manera
de sincronizar los procedimientos almacenados entre BBDD, alternativamente
mira uno de poner los SPs en la BBDD master, lo que simplifica la
administración y mantenimiento (hasta cierto punto, porque trabajar en
pruebas contra master es un tanto latazo), pero se me presenta el problema
de que tengo que dar acceso a master a todos los usuarios que utilicen la
aplicación, cosa que no me gusta nada.

Lo que es el modelo de poner todo el acceso a datos dentro de la BBDD, la
verdad que me gusta. Pero despues de leer y comprobar en el post de Eduardo
Quintás

http://geeks.ms/blogs/quintas/archi...nados.aspx

Que los procedimientos almacenados no reutilizan sus planes de ejecución si
se ejecutan en BBDD distintas, eso ya me tiró por el suelo a los SPs. Y me
dió una pista de porque los SP's me iban bien a veces (si consultaba siempre
contra la misma BBDD)

Pegas que le veo a los SPs

- la fundamental es la no reutilización de planes de ejecución entre BBDD
distintas.
- si uno se pone a escribir SPs como si fuera un lenguaje normal de
programación puede caer en el error de hacer esto:

IF condicion1
SELECT uno
ELSE
IF condicion2
SELECT dos
ELSE

hacer grandes bloques de if y consultas SELECT es de las peores cosas que se
pueden hacer con un SP, ya que: los planes de ejecución variaran en funcion
de las condiciones de la consulta, la compilación del plan de ejecución se
hace muy lenta.

En lugar de hacer eso es mucho mas optimo hacer:

IF condicion1
EXEC sp1
ELSE
IF condicion2
EXEC sp2
ELSE

¿Porque? Por la reutilización de planes de ejecución. En este segundo
ejemplo el plan de ejecución del SP principal es siempre el mismo, y el de
cada SP que es llamado tambien. Se evitan tiempos de compilación, cacheo,
...

Ventajas de los SPs

- tener todo el código de acceso centralizado en un único sitio
- facilidad de mantenimiento (incluso en producción)

Bien ante todo esto, estoy empezando a cambiar el chip y pasar mis consultas
a la capa de negocio del lado del servidor (lo que estoy haciendo es una
aplicación SOA) utilizando consultas parametrizadas (ahora decirme que las
consultas parametrizadas no se reutilizan entre BBDD y ya se me lió el
invento :)).

Al hilo de esto.

¿Como trabajar de una manera segura con los SPs en master? ¿Metiendo los SPs
en esquemas personalizados y jugando con los permisos?

Bueno .. cualquier comentario es bienvenido.

Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Siga el debate

63 respuestas

Tengo una respuesta

Preguntas similare

Cómo copio más de un archivo sobre otro???

Leer las respuestas

#16 Pablo Roca

30/04/2008 - 13:11 | Informe spam

Hola Alejandro

No he dicho lo contrario, pero como Pablo no especifica exactamente donde
reside el procedimiento y desde donde lo ejecuta, entonces no puedo
expandirme sobre el tema.

Los procedimientos almacenados son iguales y estan en cada base de datos
BD1, BD2, BD2 que tienen un modelo físico exactamente igual.

Si el mismo procedimiento
(db.owner.sp_name) se ejecuta desde distintas bases, solo un plan es
generado, si es que las condiciones para su re-uso se cumplen.

¿Cuales son esas condiciones?

Gracias por el ejemplo

Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Responder a este mensaje

#17 Alfredo Novoa

30/04/2008 - 13:28 | Informe spam

Hola Pablo,

On Wed, 30 Apr 2008 13:06:19 +0200, "Pablo Roca"
wrote:

- tener todo el código de acceso centralizado en un único sitio
- facilidad de mantenimiento (incluso en producción)

Pero para conseguir eso no hace falta usar SP.

Cierto, solo hace falta ser un poco ordenado.

Y las vistas también ayudan mucho.

Bien ante todo esto, estoy empezando a cambiar el chip y pasar mis
consultas
a la capa de negocio del lado del servidor

¿Que es la capa de negocio del lado del servidor?

Vale, llamemosla capa de negocio a secas.

¿Y que es una capa de negocio a secas? }:-)

¿No habíamos quedado en que era mejor que las reglas de negocio las
asegurase SQL Server?

Entonces. ¿En que consiste una capa de negocio que no asegura reglas
de negocio?

Saludos
Alfredo

Responder a este mensaje

#18 Alejandro Mesa

30/04/2008 - 15:38 | Informe spam

Pablo Roca,

No olvides que la data tambien es parte de esa colección llamada base de
datos. Mi pregunta en este caso es si las bases son usadas por el mismo
usuario y con la misma data, pues en ese caso para que tener bases
duplicadas. Si por el contrario, las bases son usadas por diferentes usuarios
y con deiferente data, entonces la distribucion de la data puede ser
distinta, no todas las compañias venden los mismos productos y/o servicios, y
en caso de que lo hagan, no todoas tienen la misma distribucion a nivel de
clientes.

Cada sp se adapta a las caracteristicas de la base de datos donde este
recide, cosa que me parece muy logica.

No creas que por tener un sp en la base MASTER, el optimizador usara un
unico plan cuando ejecutas a este en diferentes bases de datos. Si te fijas
en los atributos de un plan, encontraras uno cuyo valor es dbid_execute y que
para el caso de procedimientos almacenados (usare sp) es el valor de la base
desde donde se ejecuto. Este atributo tambien es parte de la clave de un
plan. Veamos un ejemplo practico.

SSMS - Query window - 1

DBCC FREEPROCCACHE
go

USE AdventureWorks
GO

EXEC dbo.sp_MSforeachtable 'print ''?'''
GO

SSMS - Query window - 2

USE Northwind
GO

EXEC dbo.sp_MSforeachtable 'print ''?'''
GO

SELECT *
FROM master..syscacheobjects
WHERE objtype = 'Proc' AND cacheobjtype = 'Compiled Plan'
GO

Habre dos ventanas de query y ejecuta los scripts en el mismo orden que he
señalado. Veras que aunque llamamos un sp que reside en la db [master], se
generan dos planes compilados, veras dos valores diferentes para
[dbid_execute], uno por cada base donde se ejecuto. En este caso el valor de
[dbid] es el mismo, pues este sp reside en la db [master].

AMB

"Pablo Roca" wrote:

Hola Alejandro

> No he dicho lo contrario, pero como Pablo no especifica exactamente donde
> reside el procedimiento y desde donde lo ejecuta, entonces no puedo
> expandirme sobre el tema.

Los procedimientos almacenados son iguales y estan en cada base de datos
BD1, BD2, BD2 que tienen un modelo físico exactamente igual.

>Si el mismo procedimiento
> (db.owner.sp_name) se ejecuta desde distintas bases, solo un plan es
> generado, si es que las condiciones para su re-uso se cumplen.

¿Cuales son esas condiciones?

Gracias por el ejemplo

Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Responder a este mensaje

#19 Alejandro Mesa

30/04/2008 - 15:43 | Informe spam

Alfredo Novoa,

El mundo donde vivimos no es solamente blanco y negro, tenemos una capa
amplia de colores. Con esto quiero decir que lo que para una compañia es
adecuado, puede que no lo sea para otra. Si tener la capa de negocio en el
lado de la db se acomoda mejor a las necesidades de el cliente, bien. Si se
acomoda mejor tenerlas en una capa fuera de el SGBD, tambien. Si estan de
acuerdo en partirla en ambos lados, tambien esta bien.

AMB

"Alfredo Novoa" wrote:

Hola Pablo,

On Wed, 30 Apr 2008 13:06:19 +0200, "Pablo Roca"
wrote:

>>>- tener todo el código de acceso centralizado en un único sitio
>>>- facilidad de mantenimiento (incluso en producción)
>>
>> Pero para conseguir eso no hace falta usar SP.
>
>Cierto, solo hace falta ser un poco ordenado.

Y las vistas también ayudan mucho.

>>>Bien ante todo esto, estoy empezando a cambiar el chip y pasar mis
>>>consultas
>>>a la capa de negocio del lado del servidor
>>
>> ¿Que es la capa de negocio del lado del servidor?
>
>Vale, llamemosla capa de negocio a secas.

¿Y que es una capa de negocio a secas? }:-)

¿No habíamos quedado en que era mejor que las reglas de negocio las
asegurase SQL Server?

Entonces. ¿En que consiste una capa de negocio que no asegura reglas
de negocio?

Saludos
Alfredo

Responder a este mensaje

#20 Carlos M. Calvelo

30/04/2008 - 15:45 | Informe spam

Hola Pablo,

On 30 apr, 13:09, "Pablo Roca" wrote:

Hola Carlos,

>Imaginémonos dos bases de datos con la estructura lógica totalmente
>igual, pero a nivel físico la una optimizada para actividades tipo
>OLTP y la otra para actividades tipo OLAP.
>Pues una tendrá pocos índices por ejemplo y la otra muchos; el mismo
>procedimiento puede estár implementado con algoritmos distintos, etc,
>etc.
>Entonces... claro que el plan de ejecución depende de la base de
>datos,
>porque depende de los datos, estadísticas, y mecanismos a nivel
>físico
>como los índices y distintas implementaciones del mismo procedimiento.

Si, ahi tienes toda la razón.

Pero te lo cambio (que es mi caso) .. imaginemonos dos bases de datos,
desplegadas a nivel físico exactamente iguales. De eso es lo que estoy
hablando.

Aun así, y hasta con los mismos datos (las bases de datos son
iguales) cada una tiene sus datos, sus índices y sus estadísticas.
Por lo tanto deberán tener cada una su plan de ejecución. Si los
datos son los mismos serán planes iguales, pero serán dos. Si los
datos son distintos, los planes pueden ser distintos.

Puedes querer centralizar el código en una base de datos, aunque
yo no utilizaría master para eso. Si tienes MiBase01, MiBase02, etc.
podrías crear una MiBaseMaster.
Pero no lo hagas para que se compartan los planes de ejecución.
Solo funciones y procedimientos que no consulten los datos, o sea
para las que el resultado solo dependerá de los parámetros tendrán
siempre el mismo plan. El plan que tu programas claro :)

Saludos,
Carlos

Responder a este mensaje

Ads by Google

Hacer una preguntaSiguiente

Tengo una respuesta

1 2 3 4 5 6 7 8 9

Busqueda sugerida