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

#31 Alfredo Novoa
30/04/2008 - 18:28 | Informe spam
On Wed, 30 Apr 2008 07:53:00 -0700, Alejandro Mesa
wrote:

Carlos M. Calvelo,

Entonces con no dar permisos de insert/update/delete ya está.
Solo al proceso ETL que es el mismísimo creador de los datos.
Y contra un SA no hay base de datos que se defienda. Es que
es precisamente este el que tiene asegurar estas cosas.



No crees que el desarrollador del paquete ETL o lo que sea que se use, pueda
cometer un error?



Lo que hay que hacer es no desactivar las reglas de integridad del
DataMart hasta que el proceso ETL esté bien probado.

De todas formas el proceso ETL debería de estar controlado por el
SGBD. Así se sigue cumpliendo rigurosamente la regla de que ninguna
aplicación externa al SGBD pueda violar cualquier regla de negocio.


Saludos
Respuesta Responder a este mensaje
#32 Alfredo Novoa
30/04/2008 - 18:45 | Informe spam
On Wed, 30 Apr 2008 13:17:22 -0300, "Maxi"
wrote:

Alfredo, demuestranos que SOA ha sido siempre SQL please, porque hasta la
version 2005 no se disponian Web Service pór ejemplo



SQL Server siempre nos ha ofrecido el servicio de gestionarnos las
bases de datos :-)

Citando al gran Dijkstra:

... what society overwhelmingly asks for is snake oil. Of course, the
snake oil has the most impressive names —otherwise you would be
selling nothing— like "Structured Analysis and Design", "Software
Engineering", "Maturity Models", "Management Information Systems",
"Integrated Project Support Environments" "Object Orientation" and
"Business Process Re-engineering" (the latter three being known as
IPSE, OO and BPR, respectively)."

EWD 1175: The strengths of the academic enterprise
Respuesta Responder a este mensaje
#33 Alfredo Novoa
30/04/2008 - 18:51 | Informe spam
On Wed, 30 Apr 2008 13:16:05 -0300, "Maxi"
wrote:

Carlos, creo que volvemos al principio, para mi las reglas de negocio no son
sinonimo de integridad, de hecho el otro dia he tenido el placer de asistir
a una importante conferencia de arquietectura donde se compartia esto mismo,
una cosa son las reglas de negocio y otra cosa las reglas de intregridad.
Ahora bien una regla de negocios se puede implementar como parte de la
integridad declarativa? pues si claro que se puede, pero es la unica forma?
no, hay otras altertivas

Una regla de integridad (tipo de datos, constraint , fk) deben estar dentro
del motor o fuera.
En la teoria y en la mayoria de los sistemas OLTP dentro, en los ETL
coincido con Alejandro.

Ahora bien, creo que estamos igual que siempre, decirle regla de negocios a
integridad, son cosas totalmente distintas y eso ya lo discutimos. La misma
palabra lo define, es una regla del negocio, y el negocio para una misma
aplicacion , misma bdd son los procesos de tus clientes.



Y luego me llamarán ogro, pero si esto no son puras tonterías a ver
que lo son.
Respuesta Responder a este mensaje
#34 Alfredo Novoa
30/04/2008 - 18:58 | Informe spam
On Wed, 30 Apr 2008 18:45:36 +0200, Alfredo Novoa
wrote:

On Wed, 30 Apr 2008 13:17:22 -0300, "Maxi"
wrote:

Alfredo, demuestranos que SOA ha sido siempre SQL please, porque hasta la
version 2005 no se disponian Web Service pór ejemplo



SQL Server siempre nos ha ofrecido el servicio de gestionarnos las
bases de datos :-)



O más claro aun: SQL Server tiene una Arquitectura Orientada a darnos
el Servicio de gestionar bases de datos :-)


Saludos
Respuesta Responder a este mensaje
#35 Carlos M. Calvelo
30/04/2008 - 19:03 | Informe spam
Hola Alejandro,

On 30 apr, 18:26, Alejandro Mesa
wrote:
Carlos M. Calvelo,

> Pero es que yo estaba reaccionando a tu proposición:



A ver si razonamos un poco eh!

Yo digo: que la integridad debe asegurarla el SGBD.

Tu me dices que:

A: En la practica se recomienda que no se usen restricciones de
integridad
A: referencial (restricciones de clave foranea) cuando se trabaja con
datamarts,

Y yo no estoy de acuerdo con esa reconmendación desde 'la práctica',
pero si se acepta esta recomendación (que, repito, no me gusta)
entonces te propongo esto:

C: Entonces con no dar permisos de insert/update/delete ya está.
C: Solo al proceso ETL que es el mismísimo creador de los datos.

Entonces vuelves tu y me dices:

A:No crees que el desarrollador del paquete ETL o lo que sea que se
use, pueda
A:cometer un error?
A:
A:Por experiencia, prefiero usar integridad referencial declarativa y
no
A:procedural. Vamos, que somos humanos.

Con lo que estoy totalmente de acuerdo desde el principio.
Pero... vamos a ver; en que quedamos? Quieres o no seguir la tal
recomendación?

Entonces te explico porqué he propuesto lo de no dar permisos.
Y ahora me dices:


No no, yo no propongo, la realidad nos fuerza a tomar esas decisiones.



En esta línea de razonamiento algo va mal eh!!!

No me parece razonable aceptar recomendaciones sin fundamento alguno
y después quejarnos de que 'la realidad' se nos impone.

No, no, no! La realidad somos nosotros.



No
todos los proyectos pueden durar el tiempo necesario para ser implementados
como se deberia. Tampoco las compañias tienen el tiempo necesario para que
las cosas se hagan como se deben. Nunca has escuchado a tu jefe decir que lo
necesitan para ayer?



Aquí puedo estar de acuerdo contigo. Pero estoy convencido que
con la formación adecuada y no haciendo simplemente lo que dice
'cualquier recomendación', el tiempo necesario para desarrollar
sería mucho mas corto.
Y en esa situación tu jefe/cliente seguirá diciendo que lo necesita
ayer!


Ademas, ni los propios software de desarrollo te brindan todas las
posibilidades.



Verdad. Pero las herramintas te aseguro que nos brindan lo que
pide el mercado. Pero como el mercado no sabe lo que quiere...



La teoria y la practica no siempre van de mano.




Y esa situación quien la crea? Los marcianos?
No tendremos nosotros (el estado de la industria) algo que ver
con el asunto?

Saludos,
Carlos
Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida