Procedimientos Almacenados

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

1) Seguridad
2) Centralizacion
3) En algunos casos Performance
4) Administracion y control

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


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Carlos M. Calvelo" escribió en el mensaje de
noticias:

Hola Oscar,

On Apr 23, 10:10 am, Oscar wrote:

Buenas:

Tengo un procedimiento almacenado que realiza la insercion,
actualizacion o el borrado segun un parametro.

ahora bien, la discusion que se generó en la empresa es si un solo
procedimiento almacenado con esas caracteristicas es mas lento o no
que generar tres procedimientos almacenados por separado segun la
accion, o sea un PA para insercion un PA para actualizacion y un PA
para borrado, debido a que de esta forma se esta SQL lo optimiza
mejor.

Una discusión mucho mas fructífera sería sobre el
para qué de estos procedimientos almacenados si
también se pueden hacer las inserciones, actualizaciones
y los borrados directamente, con mucha mas
flexibilidad que las llamadas a un procedimiento.

Saludos,
Carlos

Hola,

On Wed, 23 Apr 2008 20:45:09 -0300, "Maxi Accotto"
wrote:

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

1) Seguridad
2) Centralizacion
3) En algunos casos Performance
4) Administracion y control

Esto es un mito sin fundamento.

No hay motivo para sacarlo fuera de la base y usar sql directo

¿Para sacar el que?

Si se quiere insertar un registro en una tabla se ejecuta un insert y
ya está, no hay que sacar nada a ningún sitio.

Crear un procedimiento almacenado para hacer esto es muchas veces un
rodeo innecesario.

, es una muy
mala practica y en la mayoria de los casos esto trae a la larga muchos
problemas

Esto son tonterías.


Saludos

Hola,

Entrelineas ;-)

Esto es un mito sin fundamento.

La seguridad es un mito? la centralziacion es un mito? la administracion
mejor es un mito?
Deberia usted demostrar lo contrario para poder decir que es un mito, veamos
cada uno de ellos

Seguridad: A los logins solo le da acceso a los SP y no a los objetos con lo
cual por ejemplo desde un Excel no puede hacer un select de la tabla
Clientes

Centralizacion: Los Store residen solo en el servidor de base de datos, si
usted hace codigo por fuera puede estar en mas de una aplicacion con lo cual
no es algo centralizado

Administracion: Si usted cambia una tabla por ejemplo, puede saber cuales
objetos hacen referencia a ella con simples instrucciones

Performance: En AMB no, en Get de querys si por el cache de los SP

Si se quiere insertar un registro en una tabla se ejecuta un insert y
ya está, no hay que sacar nada a ningún sitio.

Si pero no tiene todas las ventajas que me comente anteriormente,
a) No es seguro porque hace el insert directo sobre el objeto para lo cual
necesita que el login tenga permisos sobre la tabla (por ejemplo clientes)
b) No esta centralizado, si cambio un campo en la tabla como se cuantos
insert en aplicaciones hay dando vuelta?

Esto son tonterías.

Es su opinion, las aplicaciones de mision critica en empresas importantes
usan SP tanto en SQL como en Oracle, si a usted le parece que eso son
tonterias no puedo discutir desde lo no tecnico.

Otro tema mas, supongamos una migracion de 2000 a 2005, si usted tiene el
codigo fuera del SQL deberia montar una traza y analizar si todo es
compatible, esa traza deberia ser capaz de poder captar TODAS las opciones
de todos sus sistemas para certificarlos, con lo cual un proceso de
migracion puede demorar en tiempo mucho mas de lo comun haciendo que el
costo del mismo sea mayor. Si usted tiene el codigo en el motor, es
simplemente correr una aplicacion que lo analiza y listo, se asegura 100%
que esta viendo todo.







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

Hola,

On Wed, 23 Apr 2008 20:45:09 -0300, "Maxi Accotto"
wrote:

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

1) Seguridad
2) Centralizacion
3) En algunos casos Performance
4) Administracion y control

Esto es un mito sin fundamento.

No hay motivo para sacarlo fuera de la base y usar sql directo

¿Para sacar el que?

Si se quiere insertar un registro en una tabla se ejecuta un insert y
ya está, no hay que sacar nada a ningún sitio.

Crear un procedimiento almacenado para hacer esto es muchas veces un
rodeo innecesario.

, es una muy
mala practica y en la mayoria de los casos esto trae a la larga muchos
problemas

Esto son tonterías.


Saludos

Hola,

On Thu, 24 Apr 2008 10:06:14 -0300, "Maxi"
wrote:

Esto es un mito sin fundamento.

La seguridad es un mito? la centralziacion es un mito? la administracion
mejor es un mito?

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

Seguridad: A los logins solo le da acceso a los SP y no a los objetos con lo
cual por ejemplo desde un Excel no puede hacer un select de la tabla
Clientes

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

Centralizacion: Los Store residen solo en el servidor de base de datos, si
usted hace codigo por fuera puede estar en mas de una aplicacion con lo cual
no es algo centralizado

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.

Administracion: Si usted cambia una tabla por ejemplo, puede saber cuales
objetos hacen referencia a ella con simples instrucciones

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

Lo único que hay que hacer es seguir el principio abierto/cerrado
independientemente de que uses una interfaz de tablas o una de SP.

Performance: En AMB no, en Get de querys si por el cache de los SP

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

Si se quiere insertar un registro en una tabla se ejecuta un insert y
ya está, no hay que sacar nada a ningún sitio.

Si pero no tiene todas las ventajas que me comente anteriormente,

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

a) No es seguro porque hace el insert directo sobre el objeto para lo cual
necesita que el login tenga permisos sobre la tabla (por ejemplo clientes)

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.

Curiosa lógica esa.

b) No esta centralizado, si cambio un campo en la tabla como se cuantos
insert en aplicaciones hay dando vuelta?

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

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.

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

Esto son tonterías.

Es su opinion, las aplicaciones de mision critica en empresas importantes
usan SP tanto en SQL como en Oracle, si a usted le parece que eso son
tonterias no puedo discutir desde lo no tecnico.

Y también hay muchas aplicaciones de misión crítica en empresas
importantes que no usan SP de forma generalizada para comunicarse con
el SGBD, como por ejemplo las que he hecho yo.

Otro tema mas, supongamos una migracion de 2000 a 2005, si usted tiene el
codigo fuera del SQL deberia montar una traza y analizar si todo es
compatible, esa traza deberia ser capaz de poder captar TODAS las opciones
de todos sus sistemas para certificarlos, con lo cual un proceso de
migracion puede demorar en tiempo mucho mas de lo comun haciendo que el
costo del mismo sea mayor. Si usted tiene el codigo en el motor, es
simplemente correr una aplicacion que lo analiza y listo, se asegura 100%
que esta viendo todo.

Las incompatibilidades de SQL Server 2005 con aplicaciones para SQL
Server 2000 son mínimas y además para eso están las pruebas de
regresión.


Saludos

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

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

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

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

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.

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.

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.

¿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

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

Algunos links para que lea

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

http://www.mygnet.net/articulos/sql/775/
http://www.microsoft.com/spanish/ms...tdev2.mspx

Nos vemos



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

Hola,

On Thu, 24 Apr 2008 10:06:14 -0300, "Maxi"
wrote:

Esto es un mito sin fundamento.

La seguridad es un mito? la centralziacion es un mito? la administracion
mejor es un mito?

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

Seguridad: A los logins solo le da acceso a los SP y no a los objetos con
lo
cual por ejemplo desde un Excel no puede hacer un select de la tabla
Clientes

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

Centralizacion: Los Store residen solo en el servidor de base de datos, si
usted hace codigo por fuera puede estar en mas de una aplicacion con lo
cual
no es algo centralizado

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.

Administracion: Si usted cambia una tabla por ejemplo, puede saber cuales
objetos hacen referencia a ella con simples instrucciones

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

Lo único que hay que hacer es seguir el principio abierto/cerrado
independientemente de que uses una interfaz de tablas o una de SP.

Performance: En AMB no, en Get de querys si por el cache de los SP

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

Si se quiere insertar un registro en una tabla se ejecuta un insert y
ya está, no hay que sacar nada a ningún sitio.

Si pero no tiene todas las ventajas que me comente anteriormente,

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

a) No es seguro porque hace el insert directo sobre el objeto para lo
cual
necesita que el login tenga permisos sobre la tabla (por ejemplo clientes)

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.

Curiosa lógica esa.

b) No esta centralizado, si cambio un campo en la tabla como se cuantos
insert en aplicaciones hay dando vuelta?

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

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.

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

Esto son tonterías.

Es su opinion, las aplicaciones de mision critica en empresas importantes
usan SP tanto en SQL como en Oracle, si a usted le parece que eso son
tonterias no puedo discutir desde lo no tecnico.

Y también hay muchas aplicaciones de misión crítica en empresas
importantes que no usan SP de forma generalizada para comunicarse con
el SGBD, como por ejemplo las que he hecho yo.

Otro tema mas, supongamos una migracion de 2000 a 2005, si usted tiene el
codigo fuera del SQL deberia montar una traza y analizar si todo es
compatible, esa traza deberia ser capaz de poder captar TODAS las opciones
de todos sus sistemas para certificarlos, con lo cual un proceso de
migracion puede demorar en tiempo mucho mas de lo comun haciendo que el
costo del mismo sea mayor. Si usted tiene el codigo en el motor, es
simplemente correr una aplicacion que lo analiza y listo, se asegura 100%
que esta viendo todo.

Las incompatibilidades de SQL Server 2005 con aplicaciones para SQL
Server 2000 son mínimas y además para eso están las pruebas de
regresión.


Saludos