Procedimientos Almacenados

Carlos, calmemos un poco las aguas, a ver, yo he simplemente pasado una
serie de referencias pero hay miles mas de paginas como
www.sql-server-performance.com donde podras encontrar varios articulos de
arquitectura y buenas practicas, tambien puedes revisar los documentos de
arquitectura de Microsoft en su pagina. Solo expuse algunos links si quieres
busco mas y seran tan serios como los anteriores, tu solamente me has
indicado un libro, yo quiero que me indiques un link donde diga: El uso de
SP no ayuda a la seguridad, no ayuda a la centralizacion no ayuda a la
performance. Quiero leer eso porque es lo que estamos discutiendo
basicamente, yo no digo que siempre hay que usarlos, pero digo que tienen
ventajas enormes usarlos y enumere los items donde las tienen. Ahora voy a
ir linea por linea de tus comentarios a reponderte :-) porque considero que
todo suma.
Disculpame no me has ofendido y tienes razon, tomemos esto como debe ser y
es una discusion entre 2 profesionales de forma tecnica :-)

Vamos a los puntos.


Entonces si es necesario. Hay que darle acceso; o sea permiso de
ejecución.

R: Si pero no a los objetos finales sino solo al SP y no importa donde este
SP haga la llamada ni a cuantos objetos, solo le das acceso al SP y nada
mas, entonces por ejemplo te aseguras que siempre hagan por ejemplo la
insercion de tu factura por medio del SP y no por ejemplo por medio de un
access, excel o cualquier otro sitio. Si cambias algo de logica lo haces en
el SP y la llamada puede hasta ser la misma, imaginate que el proceso ahora
requiere hacer una verificacion o bien guardar en otra tabla algo, eso lo
programas en el SP y desde tu aplicacion es transparente.

Y eso qué ventaja tiene?
Las ventajas que tu has dado (tu mismo y en links) no son ventajas
específicas de SP's, sino que también se puede decir de tablas base
y de vistas.

bueno aca hay uno de los puntos, si este punto no se comprende entonces no
podemos hablar de ventajas de los SP.
Tu no deberias permitir que los usuarios hagan insert sobre las tablas de
forma directa, de hecho ni las deberian conocer, es una cuestion de que
puedas controlar de donde y como se hace y que ademas las tablas no sean
accedidas de aplicaciones que no son las que tu has diseñado, imafginate un
soft de gestion donde tienes una tabla clientes, bien, si desde tu
aplicacion usas Select o insert el usuario que se conecta desde la misma
debe tener permisos sobre la tabla, ahora bien tu al darle permisos sobre la
tabla ese usuario puede hacer uso de ella desde cualquier otro lado, por
ejemplo un excel, una aplicacion que a el se le ocurra desarrollar etc, con
lo cual puede estar haciendo operaciones en tu sistema de forma externa y no
controlada por ti. Te imaginas los problemas de esto no?

La aplicación puede entrar de formas desconcidas para el usuario
en la bbdd. El mismo usuario puede tener un login própio para
utilizar con otras herramientas. Aunque si el sistema de seguridad
está bien diseñado no veo ninguna ventaja en ello.
Con lo de los roles me estoy refiriendo a los roles en la bbdd.
En definitiva.. se puede uno montar muchos esquemas de seguridad
distintos.

Como en forma desconocida? tu deberias tener por cada usuario de tu
aplicacion un login en el SQL para poder controlar la seguridad y ademas
monitorear, hacer auditorias, etc. Si usas un usuario generico estamos
hablando de otro esquema de sistemas y por lo general son ambientes Web.

Y no es eso lo mismo que que entre y que pueda hacer
un 'execute insert_proc'?

No porque si por ejemplo en el SP de insert tu has definido alguna regla se
ejecutara no importa de donde lo llames que siempre hara lo mismo. Ademas
hasta podrias el dia de mañana cambiar algo en el proceso de insert y solo
tocas el SP (si es que no cambian los param de entrada claro)

El código de las queries (o el de las llamadas a procedimentos
almacenados) es la interfaz entre aplicaciones y el SGBD.

En cuanto a 'la capa de acceso a datos' creía yo que estaba esta
en el SGBD.
Yo le digo al SGBD 'SELECT Esto FROM LoOtro WHERE EstoOtro' y el
SGBD 'accede a los datos' (a este nivel no me interesa como) y me
los devuelve.

Bueno aca hay un error de conceptos, la capa de acceso a datos es la que se
encarga de interactuar con la capa de datos (esta si es la base en si), en
la capa de acceso a datos te puede conectar con la capa de datos via Select
o via Stores.

Lo que si te interesa que si vos tenes un select * from clientes y lo usas
en mas de un modulo o en mas de una aplicacion, si armas un SP lo podes
reutilizar en cualquier aplicacion en cualquier sitio y no te interesa como
programador que haga ese SP solo lo llamas, con lo cual te abstraes aun mas.

Yo no digo que sean o no sean parte del modelo relacional. Digo que
no son parte de la solución al problema que trata de solucionar el
modelo. Esconder la estructura de la base de datos y un lenguaje
relacional detrás de una biblioteca de procedimientos no es la
solución.

A ver, tu deberias manejar un patron denominado Capas ok, seria la forma
correcta de hacer una aplicacion, entonces aqui tiene

UI -BI - DAL - DataBase

Los Store procedure te ayudan mucho porque desde tu DAL solamente haces un
llamado a una caja negra y es menos acoplable. Si queres reutilizar ese SP
lo podes hacer de N aplicaciones en N lenguajes de programacion. Ahora bien
vos a que solucion de modelo hablas? aca estamos hablando de programacion y
de arquitectura de aplicaciones no me queda claro que solucion no te da el
SP al modelo.

Pues el que utiliza SQL Server para eso.

Por cierto son las consultas en el SP las que tienen planes de
ejecución no el SP mismo. El plan de ejecución del SP lo programmo
yo diciendole: 'primero haces esto, después si esto es verdad
haces esto otro y si no repites esta otra cosa X veces'.

Esto si no te lo comprendo, yo estoy hablando del plan de ejecucion interno
de SQL por toda query que uno realiza, el evalua cual es el mejor camino a
realizar (que indices usar, como usarlos etc) Este calculo SQL lo hace por
cada ejecucion, en un SP ese calculo queda compilado y no debe calcularlo
siempre.

Para 'verificar cosas' tenemos los constraints. Y cuando estos
no den mas de sí, los triggers.

Si claro, primero hay que tener un bien diseño con sus constraint. Pero los
trigger no son siempre utiles para hacer verificaciones, por ejemplo debes
saber que si correc un proceso BCP o DTS los trigger se deshabilitan por
default con lo cual si has puesto logica ahi puedes estar en problemas.
Otro de los lugares donde se pone logica o verificaciones en el los Store
Procedures, entonces si tenemos un SP de grabar factura y antes de eso hay
que verificar si el cliente tiene credito por ejemplo, lo puedes poner en el
SP. Es cierto que la logica de negocios puede ir fuera y eso no esta mal,
pero si la pones en un SP estas centralizandola.
En los triggers tambien se suele poner logica de negocios, pero como veras
no es una cosa si y la otra no, pueden ser ambas, yo por lo general lo
prefiero en los SP porque el trigger esta dentro de una transaccion y si me
pongo ahi a aplicar logica voy a tener transacciones mas largas y por ende
mayores bloqueos que hasta pueden derivar en un interbloqueo.

Además nadie está diciendo (yo no por lo menos) que no tenga ninguna
aplicación los SP's. Pero el esconder la estructura de los datos
de las aplicaciones y los usuarios no es una de ellas.

Bueno como que no, es una forma de abstraccion y de seguridad para que nadie
acceda de forma directa a los objetos. Tambien comente otros factores,
reutilizacion, administracion, etc.
Hasta analisis de problemas, imaginate que tu servidor de base de datos
tiene problemas de performance, entonces se puede para ver las causas
analizar los procesos, se puede montar un profiler y ademas un performance
monitor, pero si tenemos SP hasta podriamos verificar si hay malas practicas
en ellos con el Best Practice Analyzer de Microsoft.


Bueno no creo que llegemos a un punto en comun pero si me gustaria aclarar
algunos conceptos.

Saludos

Te recomiendo los doc de arquitectura en capas de Microsoft, son muy buenos
y tambien estan en español :-)


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Carlos M. Calvelo" escribió en el mensaje
news:
Hola Maxi,

On 24 apr, 19:46, "Maxi" wrote:

Claro que se quiere seguridad y centralización. Para eso
no hacen falta procedimientos.
Demuestra tu que no es así! :)

r: Ya lo comente en otro hilo y puse una serie de links tambien, no tiene
sentido volver sobre este punto.

Los he leido así por encima y no veo nada nuevo que no haya leido
ya en otras ocasiones. No convencen.

No señor! En la bbdd tenemos algo como 'Roles'. Y desde
una aplicación el mismo usuario puede tener un role y
desde otra aplicación otro. Y el mismo usuario desde
el Query analyser puede ser... pues dba.

R: Me imagino que hablas de los roles de aplicacion, porque ya se que los
usuarios tienen roles pero lo que quizas no estas viendo o entendiendo es
que el usuario para hacer un insert o un select sobre una tabla debe tener
permiso,

Claro.

y con SP eso no es necesario, solo le das acceso al SP

Entonces si es necesario. Hay que darle acceso; o sea permiso de
ejecución.

y punto y no
debe tocar los objtos de forma directa.

Y eso qué ventaja tiene?
Las ventajas que tu has dado (tu mismo y en links) no son ventajas
específicas de SP's, sino que también se puede decir de tablas base
y de vistas.

Si hablas de roles de aplicacion para que por ejemplo un usuario no entre
con un excel y se haga un select de tu tabla clientes y se lleve
informacion, esos roles de aplicacion no siempre se puede usar porque al
hacerlo el uso del pool de conexiones no es viable

La aplicación puede entrar de formas desconcidas para el usuario
en la bbdd. El mismo usuario puede tener un login própio para
utilizar con otras herramientas. Aunque si el sistema de seguridad
está bien diseñado no veo ninguna ventaja en ello.
Con lo de los roles me estoy refiriendo a los roles en la bbdd.
En definitiva.. se puede uno montar muchos esquemas de seguridad
distintos.

Diferentes usuarios de la misma aplicación (o distintas por mi
parte) pueden tener diferentes 'Roles'. Y por lo tanto verán
subestructuras distintas de lo que es la base de datos,
dependiendo de como esté definida la seguridad.

R: Si si si, eso es 100% correcto pero lo que se trata de evitar que ese
usuario que tiene n roles pueda entrar por medio de un exce y hacer cosas,
y
que solo entre por medio de la aplicacion o los medios que esta le da, no
seria buena idea q un usuario entre con un access y haga un insert en tu
tabla SQL, estaria pasando por alto quizas muchas cosas y no es muy seguro
que digamos, si le das permiso de insert al usuario o a al rol de los
usuarios estas diciendo que ese usuario de donde se conecte puede hacer un
insert.

Y no es eso lo mismo que que entre y que pueda hacer
un 'execute insert_proc'?

El código de queries forma parte de la interfaz y no hace
falta esconderlo.

R: aca no te entiendo, si estas programando en capas esto no es asi, el
codigo de querys no es parte de la interfaz sino de la capa de acceso a
datos

El código de las queries (o el de las llamadas a procedimentos
almacenados) es la interfaz entre aplicaciones y el SGBD.

En cuanto a 'la capa de acceso a datos' creía yo que estaba esta
en el SGBD.
Yo le digo al SGBD 'SELECT Esto FROM LoOtro WHERE EstoOtro' y el
SGBD 'accede a los datos' (a este nivel no me interesa como) y me
los devuelve.

Pues está en el cache, igual que los procedimientos almacenados.

r: Cual cache? que pasa con el compilado del plan de ejecucion que tiene
el
SP?

Pues el que utiliza SQL Server para eso.

Por cierto son las consultas en el SP las que tienen planes de
ejecución no el SP mismo. El plan de ejecución del SP lo programmo
yo diciendole: 'primero haces esto, después si esto es verdad
haces esto otro y si no repites esta otra cosa X veces'.

Y yo creo que debes leer algo sobre el modelo relacional.
Sobre todo tratar de entender históricamente que problema
trataba de resolver aquel gran señor. Si entiendes aquel
problema verás que los procedimientos almacenados no
forman para nada parte de la solución.

R: No entiendo porque confundes las cosas, quien dijo que los Store son
parte del modelo relacional? son parte de como programamos y que ventajas
tiene poner el codigo ahi, el modelo relacion es otra cosa amigo.

Yo no digo que sean o no sean parte del modelo relacional. Digo que
no son parte de la solución al problema que trata de solucionar el
modelo. Esconder la estructura de la base de datos y un lenguaje
relacional detrás de una biblioteca de procedimientos no es la
solución.

No veo que ventaja tiene eso. Por qué no puede introducir
directamente el registro (cuidado: o registro(s)!) como
le dé la gana. Si tiene ese derecho lo tiene, y si no
no lo tiene. Que ventaja tiene un procedimiento almacenado
sobre eso? Ninguno.

r: parace una charla de zordos che, ya lo comente, justamente que no lo
haga
de forma directa el login y si por medio de un SP dandole solo seguridad a
ese SP y no a sus objetos.

Pues si, podemos repetir lo mismo hasta el infinito. Porque yo
te repito que a esos objetos también se le puede dar derechos
de acceso, inserción, actualización, etc. Y eso con mucha mas
granulidad haciendolo todavía mucho mas flexible en cuanto a
posibilidades durante el diseño de la bbdd.

Una factura podria al hacer un insert tener que hacerlo en 3 tablas, si
hago
un SP solo doy acceso al SP si lo hago por el otro medio debo darle
permisos
a las 3 tablas, las cuales tambien podra manipular desde una aplicacion
como
Excel haciendo un insert ya que tiene permisos. La idea es la abstraccion
y
separacion, esto ayuda a la seguridad tambien como he comentado.

Otra vez:
El nivel de abstración de una estructura de datos y un lenguaje
relacional para acceder, manipular, derivar datos es mucho mas
alto que el de una biblioteca de procedimientos.

Todas las llamadas al procedimiento son 'código'. Y
estás otra vez con el mismo problema. Si rompes la
interfaz tendrás que vértelas con tus interlocutores.
Quizás quieras ahora encapsular esta biblioteca de
procedimientos en otra biblioteca distinta para evitar
este problema? :-)

r: si claro que son codigo, pero mucho menos que lo que pueda contener el
SP
dentro, imaginate esto: Grabar una factura: Esto tiene que hacer: Grabar
la
cabecera, el detalle, verificar cosas, etc, todo en una sola transaccion.
Tu
podrias hacer un solo SP llamado Grabar Factura y desde tus aplicaciones
llamarlo, obviamente que el codigo de llamada es mucho menor y no tiene
manejo de datos, a eso me referia con este punto.

Para 'verificar cosas' tenemos los constraints. Y cuando estos
no den mas de sí, los triggers.

Además nadie está diciendo (yo no por lo menos) que no tenga ninguna
aplicación los SP's. Pero el esconder la estructura de los datos
de las aplicaciones y los usuarios no es una de ellas.

Con todos los respetos Maxi: no has demostrado nada.
Solo que tus conocimientos sobre qué es lo que realmente
trata de solucionar el modelo relacional no los tienes
muy claros. Te aconsejo que mires también la arquitectura
ansi-sparc.

R: Estamos como antes , confundiendo modelo relacional con programacion,
yo
nunca hable de modelo relacional, hable de como programar para que tus
aplicaciones sean mas seguras, facil de administrar etc.

Yo creo que en realidad estamos hablando de arquitectura.

En ningun momento
agredi a nadie como lo estas haciendo tu en gran parte del hilo,

Qué? Pero qué me dices? Donde he agredido yo?
Por si acaso me gustaría añadir que eres uno de varios miembros de
este grupo por los que siento respeto y valoro por la tarea que están
haciendo aquí ayudando a los demás.
Y hasta por ello desde aquí te doy las gracias por ello!

Pero no la jueges acusandome de haberte agredido, porque no lo he
hecho.

ademas les
pase unos links que hablan al respecto con la misma teoria que la mia,
ustedes aun no me han pasado un solo link de lo contrario los espero para
poder seguir aprendiendo todos los dias un poco mas :-)

Por favor Maxi. Esas no son referencias serias.
En cambio las referencias que se te han dado a ti si lo son:
el libro de Date y que busques información sobre la arquitectura
ansi-sparc.

Saludos,
Carlos

Hay motores relacionales que hasta hace algunas versiones no tenian Stores
Procedures ;-)

Para mi los Stores no forman parte del modelo relacional en si como tal,
pero puedo estar confundido claro


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Alfredo Novoa" escribió en el mensaje
news:

Hola Carlos,

El Thu, 24 Apr 2008 10:10:39 -0700 (PDT), Carlos M. Calvelo escribió:

Y yo creo que debes leer algo sobre el modelo relacional.
Sobre todo tratar de entender históricamente que problema
trataba de resolver aquel gran señor. Si entiendes aquel
problema verás que los procedimientos almacenados no
forman para nada parte de la solución.

No estoy de acuerdo con esto. Los procedimientos almacenados son actores
secundarios pero si forman parte del Modelo Relacional.

Si lees la definición del Modelo Relacional de Date verás que dice que uno
de los componentes del Modelo Relacional es un conjunto abierto de
operadores.


Saludos
Alfredo

El Thu, 24 Apr 2008 16:57:47 -0300, Maxi escribió:

Aun no veo links de tu parte , libros los conozco

Me imagino que alguno conocerás, ¿Pero te has leido el libro que he
recomendado?

, pero quiero que compartas
links donde afirman todo lo que tu indicas, es muy facil criticar los mios
pero no hay nada del otro lado aun

Todavía no se puede aprender bien sobre bases de datos en la Web. Aun hay
que seguir leyendo libros.

El Thu, 24 Apr 2008 17:58:01 -0300, Maxi escribió:

Hay motores relacionales que hasta hace algunas versiones no tenian Stores
Procedures ;-)

Si una cosa no tiene SP entonces no es un SGBD.

Lo de "motor" es un término poco técnico que suele incluir a los primitivos
procesadores de archivos como el DBase, PICK y otros engendros de la
antigüedad.


Saludos

El Thu, 24 Apr 2008 13:55:22 -0700 (PDT), Carlos M. Calvelo escribió:

On 24 apr, 22:18, "Carlos M. Calvelo" wrote:

Y eso con mucha mas
granulidad ...

Ui! Que patada! No será *granulación*? :)

Sería "granularidad".