Procedimientos Almacenados

On Thu, 24 Apr 2008 12:41:51 -0300, "Maxi"
wrote:

Lo que es un mito es que haya que utilizar masivamente procedimientos
almacenados para tener seguridad o para tener las cosas centralizadas.

Depende, si queres seguridad y centralizacion si. Demuestra que no es asi
:-)

Eres tú el que ha afirmado primero. Te corresponde a ti la carga de la
prueba.

Si no quieres que desde un Excel se pueda hacer un select a una tabla
de clientes pues no le das acceso y listo.

Aja, pero si no le doy permiso entonces desde la aplicacion tampoco podra
acceder ya que es el mismo usuario,

¿Y por que tiene que ser el mismo usuario?

Pero para llamar a un SP también hace falta código que puede estar en
más de una aplicación con lo cual no es algo centralizado.

Si, un simple Exec y nada mas,

Si, un simple insert y nada más.
Si, un simple delete y nada más.
Si, un simple update y nada más.
Si, un simple query y nada más. :-)

¿Que más dará hacer un simple Exec que un simple Insert?

Si, y dándole a ver dependencias con el SQL Server Management Studio,
pero no le veo ninguna relevancia.

Quien dijo que se hacia asi? hay mucha relevancia, si tocamos algo es
importante saber donde impacta, y si tengo todo centralizado eso lo puedo
saber. Si esta por fuera debo revisar todas las aplicaciones con otro metodo
pero no lo podre automatizar de forma simple

Y para tener todo centralizado no hay necesidad de usar SP de forma
generalizada para acceder al SGBD.

También hay una caché para las consultas que funciona casi igual, e
incluso mejor en algunos casos.

Cuentanos los detalles de como una query que viene por medio de SQL no
vuelve a calcular el plan de ejecucion que un estore ya tiene compilado,
muestranos documentos que hablen de ello.

Usando SQLPrepare()

http://geeks.ms/blogs/quintas/archi...nados.aspx

Volvemos al principio, creo que debes leer un poco sobre Stores Procedures y
veras que las ventajas que comento son todas reales, algunas en menor o
mayor medida pero si reales.

He leido muchas cosas sobre Stores Procedures y muchas tonterías
también. No te creas todo lo que leas y menos cuando venga de fuentes
no revisadas por pares como la MSDN o cualquier blog de por ahí.

Yo creo que tu deberías de leer bastante sobre teoría de bases de
datos, la arquitectura ANSI SPARC, los diferentes niveles de una base
de datos, las vistas y la independencia lógica.

De la misma forma que para insertar usando un procedimiento almacenado
necesitas tener permisos sobre el procedimiento almacenado. Según eso
tampoco es seguro usar procedimientos almacenados.

ehh que cosa dices amigo? a ver, el usuario X solo tiene permiso sobre
Execute del SP y no sobre los objetos que este llame (por ejemplo la tabla
clientes) con lo cual si quiere hacer un insert solo lo puede hacer por
medio del procedimiento almacenado y no por donde le guste, eso se llama
seguridad y aislamiento de responsabilidades.

A ver, el usuario "X" solo puede hacer con la tabla "Y" lo que tu le
dejes, y no tiene permiso sobre los objetos a los que esta acceda (por
ejemplo la tabla clientes) con lo cual si quiere hacer un insert solo
lo puede hacer por la tabla "Y" y no por donde le guste, eso se llama
seguridad y aislamiento de responsabilidades.

¿Y si cambias un parámetro en un procedimiento almacenado como sabes
cuantas llamadas en las aplicaciones hay dando vueltas?

Bueno es lo unico que deberias revisar pero no el codigo, no puedes
compararme revisar los param que les pasas y como los cambias a que si hay
cambios en codigo, o en estructuras de base de datos

Claro que puedo compararlo. Igual que los SP que ven las aplicaciones
no deben de cambiar, tampoco debe de cambiar la estructura de las
tablas que ven las aplicaciones. Repito que simplemente hay que
aplicar el principio abierto/cerrado al nivel externo de una base de
datos.

Las tablas expuestas a las aplicaciones no deben de cambiar de la
misma forma que no deben de cambiar los procedimientos almacenados
expuestos a las aplicaciones.

Solo teoria, en la realidad no es asi

Sospecho que lo que pasa es que no sabes lo que es el nivel externo de
una base de datos ni en que se diferencia del nivel lógico y del nivel
físico.

Algunos links para que lea

http://es.wikipedia.org/wiki/Proced...lmacenados

Este artículo además de ser bastante malo solo habla de las ventajas
de los procedimientos almacenados frente a los procedimientos de las
aplicaciones, y no dice que tengan ninguna ventaja sobre las
consultas.

http://www.mygnet.net/articulos/sql/775/

¡Menuda referencia de calidad!

http://www.microsoft.com/spanish/ms...tdev2.mspx

Esto tampoco es una referencia para tirar cohetes, pero se pueden
sacar algunas cosas:

"El plan de ejecución almacenado en caché se utiliza para otorgar a
los procedimientos almacenados una ventaja con respecto al rendimiento
de las consultas. No obstante, en las dos últimas versiones de SQL
Server, los planes de ejecución se almacenan en caché para todos los
lotes de T-SQL, independientemente de si se encuentran o no en un
procedimiento almacenado. Por tanto, el rendimiento basado en esta
característica ya no se considera un punto a favor de los
procedimientos almacenados. "

"¿Está utilizando operaciones basadas en conjuntos o está realizando
operaciones muy compatibles en T-SQL? En estos casos los
procedimientos almacenados constituyen una posibilidad, aunque las
consultas en línea también podrían funcionar."

El problema de mucha gente es que se lanzan a aprender a manejar
herramientas sin haberse estudiado antes los principios fundamentales
en los que están basadas, y por eso nos encontramos con toda esta
cantidad de artículos de usuarios llenos de confusiones.

Además, los errores de los artículos de los usuarios poco instruidos
provocan errores todavía mayores en los artículos de los lectores,
creando un círculo vicioso. Este es el origen de muchas leyendas
urbanas.

Aquí tienes un buen libro de teoría que te ayudará a comprender todas
estas cosas:

http://www.mnlibros.com.ar/DespLibro.asp?Libro–84444192



Saludos

Hola Maxi,

Oh boy! Here we go again. :)

On Apr 24, 1:45 am, "Maxi Accotto"
wrote:

Hola, es cierto que se pueden, pero no es una buena practica, el uso de
Store procedure tiene muchas ventajas

Es cierto que se pueden utilizar procedimientos almacenados,
pero su uso no es una buena práctica. ;-)
El uso de una estructura *lógica* de datos (tablas, tanto base
como vistas) y un lenguage relacional (como *pretende* ser
SQL) como interfaz entre usuarios (o grupos de), aplicaciones
(o grupo de) y la base de datos tiene muchas ventajas.

1) Seguridad

Eso no es una ventaja de los procedimientos almacenados.
La misma seguridad se le puede aplicar a tablas base, vistas
y hasta a columnas en estas.

2) Centralizacion

Eso no es una ventaja de los procedimientos almacenados.
Las tablas (base y vistas) están muy bien centralizadas.

3) En algunos casos Performance

Mito. Y muy dependiente del produto y/o versión.
Y no mezclemos conceptos lógicos con conceptos
físicos como si de cosas al mismo nivel estuvieramos
hablando.

4) Administracion y control

Lo mismo que la seguridad.

No hay motivo para sacarlo fuera de la base y usar sql directo, es una muy
mala practica y en la mayoria de los casos esto trae a la larga muchos
problemas

De lo que no hay motivo es de encapsular una interfaz de
tan de alto nivel como lo es la estructura lógica (y con
mucha razón *pública*) y un lenguaje (consultas,
manipulación de datos), en una biblioteca de procedimientos.

Eso es como encapsular código de un lenguaje
de 3a generación con un ensamblador.

Saludos,
Carlos

On Apr 24, 5:41 pm, "Maxi" wrote:

Hola, huu creo que esto va para largo ;-)

> Lo que es un mito es que haya que utilizar masivamente procedimientos
> almacenados para tener seguridad o para tener las cosas centralizadas.

Depende, si queres seguridad y centralizacion si. Demuestra que no es asi
:-)

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

> Si no quieres que desde un Excel se pueda hacer un select a una tabla
> de clientes pues no le das acceso y listo.

Aja, pero si no le doy permiso entonces desde la aplicacion tampoco podra
acceder ya que es el mismo usuario,

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.

a menos que hagas aplicaciones donde
tienes un solo usuario de conexion lo cual ya estamos en un paso anterior de
buena practica, si sus aplicaciones solo tienen un solo usuario ya es otro
tema, pero eso no es bueno.

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.

> Pero para llamar a un SP también hace falta código que puede estar en
> más de una aplicación con lo cual no es algo centralizado.

Si, un simple Exec y nada mas, el codido de querys esta en el Servidor de
base de datos donde es mejor controlable

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

> Si, y dándole a ver dependencias con el SQL Server Management Studio,
> pero no le veo ninguna relevancia.

Quien dijo que se hacia asi? hay mucha relevancia, si tocamos algo es
importante saber donde impacta,

Si estás tocando el intefaz vas a impactar a todas las
aplicaciones que la usen. Eso está claro, porque es una interfaz.

y si tengo todo centralizado eso lo puedo
saber. Si esta por fuera debo revisar todas las aplicaciones con otro metodo
pero no lo podre automatizar de forma simple

Quizás tengas que revisar la implementación que estás
haciendo de esa interfaz, sin romperla (sin romprer
contratos hechos en el pasado).

> También hay una caché para las consultas que funciona casi igual, e
> incluso mejor en algunos casos.

Cuentanos los detalles de como una query que viene por medio de SQL no
vuelve a calcular el plan de ejecucion que un estore ya tiene compilado,
muestranos documentos que hablen de ello.

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

> Pero ninguna de las ventajas que has comentado es real. Las ventajas
> falsas no cuentan.

Volvemos al principio, creo que debes leer un poco sobre Stores Procedures y
veras que las ventajas que comento son todas reales, algunas en menor o
mayor medida pero si reales.

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.

> De la misma forma que para insertar usando un procedimiento almacenado
> necesitas tener permisos sobre el procedimiento almacenado. Según eso
> tampoco es seguro usar procedimientos almacenados.

ehh que cosa dices amigo? a ver, el usuario X solo tiene permiso sobre
Execute del SP y no sobre los objetos que este llame (por ejemplo la tabla
clientes)

Pues para eso le tienes que dar permiso para ejectutar el
procedimiento. Eso es lo que está diciendo.

con lo cual si quiere hacer un insert solo lo puede hacer por
medio del procedimiento almacenado y no por donde le guste, eso se llama
seguridad y aislamiento de responsabilidades.

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.

> ¿Y si cambias un parámetro en un procedimiento almacenado como sabes
> cuantas llamadas en las aplicaciones hay dando vueltas?

Bueno es lo unico que deberias revisar pero no el codigo, no puedes
compararme revisar los param que les pasas y como los cambias a que si hay
cambios en codigo, o en estructuras de base de datos

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? :-)

> Las tablas expuestas a las aplicaciones no deben de cambiar de la
> misma forma que no deben de cambiar los procedimientos almacenados
> expuestos a las aplicaciones.

Solo teoria, en la realidad no es asi

> Todo es lo mismo, eso de las ventajas de los procedimientos
> almacenados es una extraña y reciente leyenda urbana sin fundamento.

Su opinion, muy alejada de la realidad, le recomiendo que lea mejor sobre SP
y aca cerramos el tema porque no tiene sentido seguir el hilo, ya le he
demostrado y enumeado porque usar SP, si usted no opina lo mismo es
simplemete su opinion aun sin fundamentos solidos claro :-)

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.

Algunos links para que lea

Si si. Lee! :)

Saludos,
Carlos

Corto, yoya te he pasado articulos donde afirman lo que comento, tu ahora
pasame articulos donde afirman lo que tu comentas y no lo que yo :-), sino
es simplemente tu opinion y no hay nada que la respalde :-)


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

On Thu, 24 Apr 2008 12:41:51 -0300, "Maxi"
wrote:

Lo que es un mito es que haya que utilizar masivamente procedimientos
almacenados para tener seguridad o para tener las cosas centralizadas.

Depende, si queres seguridad y centralizacion si. Demuestra que no es asi
:-)

Eres tú el que ha afirmado primero. Te corresponde a ti la carga de la
prueba.

Si no quieres que desde un Excel se pueda hacer un select a una tabla
de clientes pues no le das acceso y listo.

Aja, pero si no le doy permiso entonces desde la aplicacion tampoco podra
acceder ya que es el mismo usuario,

¿Y por que tiene que ser el mismo usuario?

Pero para llamar a un SP también hace falta código que puede estar en
más de una aplicación con lo cual no es algo centralizado.

Si, un simple Exec y nada mas,

Si, un simple insert y nada más.
Si, un simple delete y nada más.
Si, un simple update y nada más.
Si, un simple query y nada más. :-)

¿Que más dará hacer un simple Exec que un simple Insert?

Si, y dándole a ver dependencias con el SQL Server Management Studio,
pero no le veo ninguna relevancia.

Quien dijo que se hacia asi? hay mucha relevancia, si tocamos algo es
importante saber donde impacta, y si tengo todo centralizado eso lo puedo
saber. Si esta por fuera debo revisar todas las aplicaciones con otro
metodo
pero no lo podre automatizar de forma simple

Y para tener todo centralizado no hay necesidad de usar SP de forma
generalizada para acceder al SGBD.

También hay una caché para las consultas que funciona casi igual, e
incluso mejor en algunos casos.

Cuentanos los detalles de como una query que viene por medio de SQL no
vuelve a calcular el plan de ejecucion que un estore ya tiene compilado,
muestranos documentos que hablen de ello.

Usando SQLPrepare()

http://geeks.ms/blogs/quintas/archi...nados.aspx

Volvemos al principio, creo que debes leer un poco sobre Stores Procedures
y
veras que las ventajas que comento son todas reales, algunas en menor o
mayor medida pero si reales.

He leido muchas cosas sobre Stores Procedures y muchas tonterías
también. No te creas todo lo que leas y menos cuando venga de fuentes
no revisadas por pares como la MSDN o cualquier blog de por ahí.

Yo creo que tu deberías de leer bastante sobre teoría de bases de
datos, la arquitectura ANSI SPARC, los diferentes niveles de una base
de datos, las vistas y la independencia lógica.

De la misma forma que para insertar usando un procedimiento almacenado
necesitas tener permisos sobre el procedimiento almacenado. Según eso
tampoco es seguro usar procedimientos almacenados.

ehh que cosa dices amigo? a ver, el usuario X solo tiene permiso sobre
Execute del SP y no sobre los objetos que este llame (por ejemplo la tabla
clientes) con lo cual si quiere hacer un insert solo lo puede hacer por
medio del procedimiento almacenado y no por donde le guste, eso se llama
seguridad y aislamiento de responsabilidades.

A ver, el usuario "X" solo puede hacer con la tabla "Y" lo que tu le
dejes, y no tiene permiso sobre los objetos a los que esta acceda (por
ejemplo la tabla clientes) con lo cual si quiere hacer un insert solo
lo puede hacer por la tabla "Y" y no por donde le guste, eso se llama
seguridad y aislamiento de responsabilidades.

¿Y si cambias un parámetro en un procedimiento almacenado como sabes
cuantas llamadas en las aplicaciones hay dando vueltas?

Bueno es lo unico que deberias revisar pero no el codigo, no puedes
compararme revisar los param que les pasas y como los cambias a que si hay
cambios en codigo, o en estructuras de base de datos

Claro que puedo compararlo. Igual que los SP que ven las aplicaciones
no deben de cambiar, tampoco debe de cambiar la estructura de las
tablas que ven las aplicaciones. Repito que simplemente hay que
aplicar el principio abierto/cerrado al nivel externo de una base de
datos.

Las tablas expuestas a las aplicaciones no deben de cambiar de la
misma forma que no deben de cambiar los procedimientos almacenados
expuestos a las aplicaciones.

Solo teoria, en la realidad no es asi

Sospecho que lo que pasa es que no sabes lo que es el nivel externo de
una base de datos ni en que se diferencia del nivel lógico y del nivel
físico.

Algunos links para que lea

http://es.wikipedia.org/wiki/Proced...lmacenados

Este artículo además de ser bastante malo solo habla de las ventajas
de los procedimientos almacenados frente a los procedimientos de las
aplicaciones, y no dice que tengan ninguna ventaja sobre las
consultas.

http://www.mygnet.net/articulos/sql/775/

¡Menuda referencia de calidad!

http://www.microsoft.com/spanish/ms...tdev2.mspx

Esto tampoco es una referencia para tirar cohetes, pero se pueden
sacar algunas cosas:

"El plan de ejecución almacenado en caché se utiliza para otorgar a
los procedimientos almacenados una ventaja con respecto al rendimiento
de las consultas. No obstante, en las dos últimas versiones de SQL
Server, los planes de ejecución se almacenan en caché para todos los
lotes de T-SQL, independientemente de si se encuentran o no en un
procedimiento almacenado. Por tanto, el rendimiento basado en esta
característica ya no se considera un punto a favor de los
procedimientos almacenados. "

"¿Está utilizando operaciones basadas en conjuntos o está realizando
operaciones muy compatibles en T-SQL? En estos casos los
procedimientos almacenados constituyen una posibilidad, aunque las
consultas en línea también podrían funcionar."

El problema de mucha gente es que se lanzan a aprender a manejar
herramientas sin haberse estudiado antes los principios fundamentales
en los que están basadas, y por eso nos encontramos con toda esta
cantidad de artículos de usuarios llenos de confusiones.

Además, los errores de los artículos de los usuarios poco instruidos
provocan errores todavía mayores en los artículos de los lectores,
creando un círculo vicioso. Este es el origen de muchas leyendas
urbanas.

Aquí tienes un buen libro de teoría que te ayudará a comprender todas
estas cosas:

http://www.mnlibros.com.ar/DespLibro.asp?Libro–84444192



Saludos

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.


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

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.


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


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?

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.

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.
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.

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.

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. En ningun momento
agredi a nadie como lo estas haciendo tu en gran parte del hilo, 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 :-) pero mientras tanto
me parece que es una simple discusion sin sentido, no vamos a llegar a
ningun lado asi.
Pero bueno, yo ya expuse lo mio y mostre articulos al respecto, les toca a
ustedes mostrar documentacion :-)

Saludos

pd: para mi este hilo se termino aqui, quizas otro colega quiera aportar
algo mas..




-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Carlos M. Calvelo" escribió en el mensaje
news:
On Apr 24, 5:41 pm, "Maxi" wrote:

Hola, huu creo que esto va para largo ;-)

> Lo que es un mito es que haya que utilizar masivamente procedimientos
> almacenados para tener seguridad o para tener las cosas centralizadas.

Depende, si queres seguridad y centralizacion si. Demuestra que no es asi
:-)

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

> Si no quieres que desde un Excel se pueda hacer un select a una tabla
> de clientes pues no le das acceso y listo.

Aja, pero si no le doy permiso entonces desde la aplicacion tampoco podra
acceder ya que es el mismo usuario,

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.

a menos que hagas aplicaciones donde
tienes un solo usuario de conexion lo cual ya estamos en un paso anterior
de
buena practica, si sus aplicaciones solo tienen un solo usuario ya es otro
tema, pero eso no es bueno.

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.

> Pero para llamar a un SP también hace falta código que puede estar en
> más de una aplicación con lo cual no es algo centralizado.

Si, un simple Exec y nada mas, el codido de querys esta en el Servidor de
base de datos donde es mejor controlable

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

> Si, y dándole a ver dependencias con el SQL Server Management Studio,
> pero no le veo ninguna relevancia.

Quien dijo que se hacia asi? hay mucha relevancia, si tocamos algo es
importante saber donde impacta,

Si estás tocando el intefaz vas a impactar a todas las
aplicaciones que la usen. Eso está claro, porque es una interfaz.

y si tengo todo centralizado eso lo puedo
saber. Si esta por fuera debo revisar todas las aplicaciones con otro
metodo
pero no lo podre automatizar de forma simple

Quizás tengas que revisar la implementación que estás
haciendo de esa interfaz, sin romperla (sin romprer
contratos hechos en el pasado).

> También hay una caché para las consultas que funciona casi igual, e
> incluso mejor en algunos casos.

Cuentanos los detalles de como una query que viene por medio de SQL no
vuelve a calcular el plan de ejecucion que un estore ya tiene compilado,
muestranos documentos que hablen de ello.

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

> Pero ninguna de las ventajas que has comentado es real. Las ventajas
> falsas no cuentan.

Volvemos al principio, creo que debes leer un poco sobre Stores Procedures
y
veras que las ventajas que comento son todas reales, algunas en menor o
mayor medida pero si reales.

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.

> De la misma forma que para insertar usando un procedimiento almacenado
> necesitas tener permisos sobre el procedimiento almacenado. Según eso
> tampoco es seguro usar procedimientos almacenados.

ehh que cosa dices amigo? a ver, el usuario X solo tiene permiso sobre
Execute del SP y no sobre los objetos que este llame (por ejemplo la tabla
clientes)

Pues para eso le tienes que dar permiso para ejectutar el
procedimiento. Eso es lo que está diciendo.

con lo cual si quiere hacer un insert solo lo puede hacer por
medio del procedimiento almacenado y no por donde le guste, eso se llama
seguridad y aislamiento de responsabilidades.

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.

> ¿Y si cambias un parámetro en un procedimiento almacenado como sabes
> cuantas llamadas en las aplicaciones hay dando vueltas?

Bueno es lo unico que deberias revisar pero no el codigo, no puedes
compararme revisar los param que les pasas y como los cambias a que si hay
cambios en codigo, o en estructuras de base de datos

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? :-)

> Las tablas expuestas a las aplicaciones no deben de cambiar de la
> misma forma que no deben de cambiar los procedimientos almacenados
> expuestos a las aplicaciones.

Solo teoria, en la realidad no es asi

> Todo es lo mismo, eso de las ventajas de los procedimientos
> almacenados es una extraña y reciente leyenda urbana sin fundamento.

Su opinion, muy alejada de la realidad, le recomiendo que lea mejor sobre
SP
y aca cerramos el tema porque no tiene sentido seguir el hilo, ya le he
demostrado y enumeado porque usar SP, si usted no opina lo mismo es
simplemete su opinion aun sin fundamentos solidos claro :-)

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.

Algunos links para que lea

Si si. Lee! :)

Saludos,
Carlos