Procedimientos Almacenados

El Thu, 24 Apr 2008 14:46:57 -0300, Maxi escribió:

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

Pusiste una serie de enlaces de baja calidad que incluso te contradecían en
buena parte.

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, y con SP eso no es necesario, solo le das acceso al SP y punto y no
debe tocar los objtos de forma directa.

Pero el SP también es un objeto como otro cualquiera, y da igual dar acceso
a un SP que a cualquier otro objeto.

Está claro que no conoces la diferencia entre los diferentes niveles de la
arquitectura ANSI SPARC.

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

¿Y por que no?

en tu
tabla SQL

Si dejas que el usuario vea una tabla entonces también es su tabla SQL.

, estaria pasando por alto quizas muchas cosas y no es muy seguro
que digamos,

Solo es inseguro si el DBA ha hecho un mal trabajo y ha pasado por alto
cosas.

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.

Lo cual es una ventaja.

R: No entiendo porque confundes las cosas, quien dijo que los Store son
parte del modelo relacional?

Christopher Date por ejemplo. ¿Te suena?

Si quieres te copio alguna cita exacta.

son parte de como programamos y que ventajas
tiene poner el codigo ahi, el modelo relacion es otra cosa amigo.

Otra cosa que no pareces conocer muy bien.

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.

Parece una charla con un sordo. También le puedes dar acceso a una vista y
no a sus "objetos".

Una factura podria al hacer un insert tener que hacerlo en 3 tablas, si hago
un SP solo doy acceso al SP

Si para crear una factura hay que insertar en tres tablas entonces sería
horriblemente incómodo hacerlo usando un único SP. Yo nunca he visto ningún
sistema en el que se creen facturas con líneas usando un único SP.

si lo hago por el otro medio debo darle permisos
a las 3 tablas,

Y si creas las facturas usando 9 SP le tienes que dar permiso a los 9 SP.
No te das cuenta del poco sentido que tiene lo que dices.

las cuales tambien podra manipular desde una aplicacion como
Excel haciendo un insert ya que tiene permisos.

Y no habría nada de malo en ello. Más bien todo lo contrario le estás dando
más posibilidades al usuario de hacer su trabajo de forma eficaz.

A mi los usuarios y los compañeros de soporte me piden con frecuencia que
se puedan manipular los datos usando Excel, por que para algunas cosas es
la forma más rápida, sobre todo para la gente que no sabe usar una consola
SQL.

Además también podrían usar el SQL Management Studio para insertar facturas
usando tu SP. La única diferencia es que el SP sería más incómodo, igual
que lo es para los programadores.

La idea es la abstraccion y
separacion, esto ayuda a la seguridad tambien como he comentado.

Lo siento, pero no sabes muy bien de lo que estás hablando.

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.

Grabar una factura a través de un SP requiere un montón de código de
aplicación para preparar la llamada, en cambio si usas una herramienta RAD
que acceda a tablas se puede hacer de forma visual sin escribir nada de
código.

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.

Estás hablando de como programar un SGBD basado en el Modelo Relacional.

No creo que sea muy recomendable que un DBA de SQL Server no conozca el
Modelo Relacional.

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

Yo no he visto que Carlos agrediese a nadie, y tu nos has llamado sordos
;-)

, ademas les
pase unos links que hablan al respecto con la misma teoria que la mia,

Yo también puedo encontrar enlaces que defiendan cualquier tontería como
los platillos volantes o los vampiros. Lo dices como si eso tuviese algún
valor.

ustedes aun no me han pasado un solo link

¿No has visto el enlace del libro que puse?

Muchos lo consideran el mejor libro de introducción a las bases de datos y
es el libro de texto de mucha universidades, y una lectura recomendada en
casi todas las demás.

Yo lo considero imprescindible para cualquier profesional serio.


Saludos

Aun no veo links de tu parte , libros los conozco, 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


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

El Thu, 24 Apr 2008 14:46:57 -0300, Maxi escribió:

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

Pusiste una serie de enlaces de baja calidad que incluso te contradecían
en
buena parte.

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, y con SP eso no es necesario, solo le das acceso al SP y punto y
no
debe tocar los objtos de forma directa.

Pero el SP también es un objeto como otro cualquiera, y da igual dar
acceso
a un SP que a cualquier otro objeto.

Está claro que no conoces la diferencia entre los diferentes niveles de la
arquitectura ANSI SPARC.

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

¿Y por que no?

en tu
tabla SQL

Si dejas que el usuario vea una tabla entonces también es su tabla SQL.

, estaria pasando por alto quizas muchas cosas y no es muy seguro
que digamos,

Solo es inseguro si el DBA ha hecho un mal trabajo y ha pasado por alto
cosas.

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.

Lo cual es una ventaja.

R: No entiendo porque confundes las cosas, quien dijo que los Store son
parte del modelo relacional?

Christopher Date por ejemplo. ¿Te suena?

Si quieres te copio alguna cita exacta.

son parte de como programamos y que ventajas
tiene poner el codigo ahi, el modelo relacion es otra cosa amigo.

Otra cosa que no pareces conocer muy bien.

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.

Parece una charla con un sordo. También le puedes dar acceso a una vista y
no a sus "objetos".

Una factura podria al hacer un insert tener que hacerlo en 3 tablas, si
hago
un SP solo doy acceso al SP

Si para crear una factura hay que insertar en tres tablas entonces sería
horriblemente incómodo hacerlo usando un único SP. Yo nunca he visto
ningún
sistema en el que se creen facturas con líneas usando un único SP.

si lo hago por el otro medio debo darle permisos
a las 3 tablas,

Y si creas las facturas usando 9 SP le tienes que dar permiso a los 9 SP.
No te das cuenta del poco sentido que tiene lo que dices.

las cuales tambien podra manipular desde una aplicacion como
Excel haciendo un insert ya que tiene permisos.

Y no habría nada de malo en ello. Más bien todo lo contrario le estás
dando
más posibilidades al usuario de hacer su trabajo de forma eficaz.

A mi los usuarios y los compañeros de soporte me piden con frecuencia que
se puedan manipular los datos usando Excel, por que para algunas cosas es
la forma más rápida, sobre todo para la gente que no sabe usar una consola
SQL.

Además también podrían usar el SQL Management Studio para insertar
facturas
usando tu SP. La única diferencia es que el SP sería más incómodo, igual
que lo es para los programadores.

La idea es la abstraccion y
separacion, esto ayuda a la seguridad tambien como he comentado.

Lo siento, pero no sabes muy bien de lo que estás hablando.

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.

Grabar una factura a través de un SP requiere un montón de código de
aplicación para preparar la llamada, en cambio si usas una herramienta RAD
que acceda a tablas se puede hacer de forma visual sin escribir nada de
código.

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.

Estás hablando de como programar un SGBD basado en el Modelo Relacional.

No creo que sea muy recomendable que un DBA de SQL Server no conozca el
Modelo Relacional.

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

Yo no he visto que Carlos agrediese a nadie, y tu nos has llamado sordos
;-)

, ademas les
pase unos links que hablan al respecto con la misma teoria que la mia,

Yo también puedo encontrar enlaces que defiendan cualquier tontería como
los platillos volantes o los vampiros. Lo dices como si eso tuviese algún
valor.

ustedes aun no me han pasado un solo link

¿No has visto el enlace del libro que puse?

Muchos lo consideran el mejor libro de introducción a las bases de datos y
es el libro de texto de mucha universidades, y una lectura recomendada en
casi todas las demás.

Yo lo considero imprescindible para cualquier profesional serio.


Saludos

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

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

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

Y eso con mucha mas
granulidad ...

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