Otro debate (mas) sobre los Procedimientos Almacenados

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.

> > En la practica se recomienda que no se usen restricciones de integridad
> > referencial

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.

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

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.

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

Hola Alejandro,

On 30 apr, 16:53, 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?

Si claro!

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

En eso estamos de acuerdo. Y no solo la referencial. Y si no puede
ser declarativa, pues (de mala gana!) tendrá que ser procedimental.
Lo esencial es la centralización de las reglas.

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

> > > En la practica se recomienda que no se usen restricciones de integridad
> > > referencial

Que no estoy de acuerdo con esa recomendación. Pero si se se
le hace caso a esta recomendación entonces la integridad es
reponsabilidad del proceso ETL y para los demas usuarios/
aplicaciones no se darían entonces permisos de acturalización
de datos, para evitar todavía más 'posibles errores'.

Eso era todo.

Saludos,
Carlos