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

Preguntas similare

Leer las respuestas

#11 Alfredo Novoa
30/04/2008 - 12:37 | Informe spam
Hola Pablo,

On Mon, 28 Apr 2008 14:00:26 +0200, "Pablo Roca"
wrote:

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.



A mi me parece una mala idea. Cada base de datos debería de tener sus
propios SP y ser independiente de Master.

Además, si te va lento lo único que tienes que hacer para mejorar la
velocidad es repartir las bases de datos entre diferentes servidores.

Hasta llegar a 60 servidores hay bastante margen para mejorar. :-D

Ventajas de los SPs

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

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?

(lo que estoy haciendo es una
aplicación SOA) utilizando consultas parametrizadas



SQL Server ha sido SOA desde el principio de los tiempos.

(ahora decirme que las
consultas parametrizadas no se reutilizan entre BBDD y ya se me lió el
invento :)).



Parece que va a haber que tirar de las orejas a Eduardo, por que de
eso nada de nada.


Saludos
Alfredo
Respuesta Responder a este mensaje
#12 Pablo Roca
30/04/2008 - 13:03 | Informe spam
Hola Alejandro,

Las consultas adhoc y las consultas parametrizadas (sp_executesql) tampoco
reusan un plan de ejecucion si estas se ejecutan desde diferentes base de
datos.



vaya!

Gracias por toda la información Alejandro. En el otro post te amplio
información.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#13 Pablo Roca
30/04/2008 - 13:06 | Informe spam
Hola Alfredo,

A mi me parece una mala idea. Cada base de datos debería de tener sus
propios SP y ser independiente de Master.



Si, la verdad que trabajar contra master no parece ser lo mas adecuado.

Además, si te va lento lo único que tienes que hacer para mejorar la
velocidad es repartir las bases de datos entre diferentes servidores.

Hasta llegar a 60 servidores hay bastante margen para mejorar. :-D



:))))

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

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.

(ahora decirme que las
consultas parametrizadas no se reutilizan entre BBDD y ya se me lió el
invento :)).



Parece que va a haber que tirar de las orejas a Eduardo, por que de
eso nada de nada.



jajajaja


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#14 Pablo Roca
30/04/2008 - 13:07 | Informe spam
Hola Eduardo,

"Eduardo" escribió en el mensaje
news:
Yo la verdad de tanto leer cosas sobre los planes de ejecución he
decidido: ignorar todo ;) Cuando tenga q usar una consulta ad-hoc, la uso
y punto; una preparada, la uso y punto; un sp, lo uso y punto. Vamos, que
SS no debería ser tan poco 'smart' ;)



Vaya! :)

Aunque creo que la reutilización del plan de ejecución es interesante. ¿No?


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
#15 Pablo Roca
30/04/2008 - 13:09 | Informe spam
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.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida