Forums Últimos mensajes - Powered by IBM
 
Tags Palabras claves

Otro debate (mas) sobre los Procedimientos Almacenados

28/04/2008 - 14:00 por Pablo Roca | Informe spam
Ayuda Hacer una pregunta
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
email Siga el debateRespuesta 63 respuestasRespuesta Tengo una respuesta

Preguntas similare

Leer las respuestas

#21 Carlos M. Calvelo
30/04/2008 - 16:01 | Informe spam
Hola Alejandro,

On 30 apr, 15:43, Alejandro Mesa
wrote:
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.




Eso de que 'todo está bien' lo interpreto como 'todas estas opciones
van a funcionar' o 'es como lo ha ideado alguien porque esí lo
entendía' o 'ya tenemos cierta infraestructura y tendremos que
seguir así' o etc, etc.

Pero lógicamente no todas esas opciones están bien, porque 'lógica
de negocio' son reglas de integridad de datos y para eso tenemos
SGBD's. Y asegurar de forma centralizada la consistencia de los
datos con las regas me parece que será siempre lo que mejor se
acomoda a las necesidades del cliente.

A ver si se va a repetir aquí ahora la otra discusion otra vez. :)

Saludos,
Carlos
Respuesta Responder a este mensaje
#22 Alejandro Mesa
30/04/2008 - 16:15 | Informe spam
Carlos M. Calvelo,

En teoria asi es, en la practica ya veremos. Te pongo un ejemplo practico.

En la practica se recomienda que no se usen restricciones de integridad
referencial (restricciones de clave foranea) cuando se trabaja con datamarts,
pues esto hace demasiado lento el proceso de ETL, sobre todo cuando se
procesan cientos de miles de filas en una cada ejecucion del proceso. Se
supone que los usuarios no ejecuten operaciones de INSERT / UPDATE / DELETE
contra las tablas del datamart de forma directa, y que el chequeo referencial
se haga en el proceso ETL. Eso deja la db abierta, a que si algun usuario de
la db, puede ser un desarrollador o administrador, tiene los derechos de
sobre estas operaciones, que en algun momento pueda ocurrir lo no esperado.

Otro ejemplo es cuando escalamos el formato de entrada hacia la capa de
presentacion, duplicando el chequeo.

Como vez hay un poquito para todos.

AMB

"Carlos M. Calvelo" wrote:

Hola Alejandro,

On 30 apr, 15:43, Alejandro Mesa
wrote:
> 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.
>

Eso de que 'todo está bien' lo interpreto como 'todas estas opciones
van a funcionar' o 'es como lo ha ideado alguien porque esí lo
entendía' o 'ya tenemos cierta infraestructura y tendremos que
seguir así' o etc, etc.

Pero lógicamente no todas esas opciones están bien, porque 'lógica
de negocio' son reglas de integridad de datos y para eso tenemos
SGBD's. Y asegurar de forma centralizada la consistencia de los
datos con las regas me parece que será siempre lo que mejor se
acomoda a las necesidades del cliente.

A ver si se va a repetir aquí ahora la otra discusion otra vez. :)

Saludos,
Carlos

Respuesta Responder a este mensaje
#23 Carlos M. Calvelo
30/04/2008 - 16:37 | Informe spam
Hola Alejandro,

On 30 apr, 16:15, Alejandro Mesa
wrote:
Carlos M. Calvelo,

En teoria asi es, en la practica ya veremos. Te pongo un ejemplo practico.

En la practica se recomienda que no se usen restricciones de integridad
referencial (restricciones de clave foranea) cuando se trabaja con datamarts,
pues esto hace demasiado lento el proceso de ETL, sobre todo cuando se
procesan cientos de miles de filas en una cada ejecucion del proceso. Se
supone que los usuarios no ejecuten operaciones de INSERT / UPDATE / DELETE
contra las tablas del datamart de forma directa, y que el chequeo referencial
se haga en el proceso ETL. Eso deja la db abierta, a que si algun usuario de
la db, puede ser un desarrollador o administrador, tiene los derechos de
sobre estas operaciones, que en algun momento pueda ocurrir lo no esperado.



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.


Otro ejemplo es cuando escalamos el formato de entrada hacia la capa de
presentacion, duplicando el chequeo.



Esa duplicación puede ser razonable para evitar demasiados viajes
al SGBD. Pero que se controle algo en la aplicación no significa
que el sgbd ya no deba hacerlo. Piensa que aplicaciones puede
haber muchas y cada una con sus propias ideas de lo que son las
reglas, a veces hasta contradiciendose sin saberlo unas con otras.
Por eso es necesaria la centralización de las reglas de integridad.

Saludos,
Carlos
Respuesta Responder a este mensaje
#24 Alejandro Mesa
30/04/2008 - 16:53 | Informe spam
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?

Por experiencia, prefiero usar integridad referencial declarativa y no
procedural. Vamos, que somos humanos.

AMB


"Carlos M. Calvelo" wrote:

Hola Alejandro,

On 30 apr, 16:15, Alejandro Mesa
wrote:
> Carlos M. Calvelo,
>
> En teoria asi es, en la practica ya veremos. Te pongo un ejemplo practico.
>
> En la practica se recomienda que no se usen restricciones de integridad
> referencial (restricciones de clave foranea) cuando se trabaja con datamarts,
> pues esto hace demasiado lento el proceso de ETL, sobre todo cuando se
> procesan cientos de miles de filas en una cada ejecucion del proceso. Se
> supone que los usuarios no ejecuten operaciones de INSERT / UPDATE / DELETE
> contra las tablas del datamart de forma directa, y que el chequeo referencial
> se haga en el proceso ETL. Eso deja la db abierta, a que si algun usuario de
> la db, puede ser un desarrollador o administrador, tiene los derechos de
> sobre estas operaciones, que en algun momento pueda ocurrir lo no esperado..

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.

>
> Otro ejemplo es cuando escalamos el formato de entrada hacia la capa de
> presentacion, duplicando el chequeo.

Esa duplicación puede ser razonable para evitar demasiados viajes
al SGBD. Pero que se controle algo en la aplicación no significa
que el sgbd ya no deba hacerlo. Piensa que aplicaciones puede
haber muchas y cada una con sus propias ideas de lo que son las
reglas, a veces hasta contradiciendose sin saberlo unas con otras.
Por eso es necesaria la centralización de las reglas de integridad.

Saludos,
Carlos

Respuesta Responder a este mensaje
#25 Alfredo Novoa
30/04/2008 - 17:31 | Informe spam
On Wed, 30 Apr 2008 06:43:00 -0700, Alejandro Mesa
wrote:

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.



Si claro, si hacer las cosas mal se acomoda mejor a las necesidades
del cliente, bien. Y si están de acuerdo en que 2 + 2 = 5, también
está bien.

Lo que pasa es que parece que Pablo se ha construido un SGBD de
propósito específico que usa SQL Server por detrás . De esa forma la
capa de negocio sigue dentro del SGBD que ya que el SGBD no es SQL
Server sino el servidor de Pablo.

Así que si las aplicaciones se comunican con el SGBD a base de
ejecutar procedimientos entonces estamos en las mismas que si usamos
SP para todo :-(



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