Acceso a Datos (Mejores practicas)

18/05/2007 - 20:28 por ivan13pocaterra | Informe spam
Buenas Amigos:

Siempre en busqueda de las buenas practicas de desarrollo, para poder
implementarlas en los sistemas en los que trabajo, tengo una duda
sobre el uso o no de stored procedures para el acceso a datos.

1.- Me encontre con una opinion que indica que para el acceso a datos,
no es necesario el uso masivo de stored procedures. Es decir, que si
yo necesito hacer un un simple "Insert", "Update", "Delete" o un
"Select", los mismo se pueden colocar explicitame y directamente en la
capa de datos o de negocio de la aplicación. Y dejar solo los stored
procedures para realizar operaciones mas complejas (que luego se
llamarian desde la aplicación .NET).

2.- Otra opinión es que el acceso a datos solo debe ser realizado
mediante el uso exclusivo de stored procedures (asi sea un simple
select). Es decir, en todo el codigo de la aplicación no debe existir
un solo "Select", "Insert", "Update" o "Delete".

Bueno.. escucho opiniones de los expertos!

Saludos
 

Leer las respuestas

#1 Alberto Poblacion
19/05/2007 - 10:03 | Informe spam
wrote in message
news:
2.- Otra opinión es que el acceso a datos solo debe ser realizado
mediante el uso exclusivo de stored procedures (asi sea un simple
select). Es decir, en todo el codigo de la aplicación no debe existir
un solo "Select", "Insert", "Update" o "Delete".



Esta opción está un poco obsoleta. Antiguamente se recomendaba trabajar
así porque el procedimiento almacenado se guardaba ya optimizado, con lo que
no se perdía tiempo en volver a calcular un plan de ejecución para la
sentencia cada vez que se hacía una llamada. Otra ventaja era que se
evitaban los ataques de inyección de Sql al forzar a encapsular en
parámetros todos los datos enviados al procedimiento. Y una ventaja más era
que se podían afinar los permisos de ejecución, dando a los usuarios
únicamente permiso de ejecución sobre el procedimiento almacenado, pero no
para acceder directamente a las tablas.

Con las versiones modernas de Sql Server y ado.net estas ventajas han
quedado superadas. Sql Server mantiene un caché de planes de ejecución, con
lo que las sentencias no tienen que re-optimizarse si se ejecutan
repetidamente. Con ado.net las sentencias se pueden parametrizar
directamente sin necesidad de que estén dentro de un procedimiento
almacenado. Y el control de acceso a las tablas se puede afinar bastante sin
necesidad de intercalar un procedimiento almacenado.

Así que, modernamente, es superfluo usar un procedimiento almacenado para
encapsular una simple sentencia. Merece la pena reservarlos solo para las
operaciones complicadas.

Cabe señalar que en el último "MVP Summit" se planteó este tema en una de
las sesiones a las que asistí, y el "gurú" de Sql Server que asistía por
parte de Microsoft (lo siento, se me olvidó su nombre) vino a decir más o
menos esto mismo, y aprovechó para quejarse de la "desincronización" entre
departamentos, ya que mientras en la parte de Sql Server hacen cosas como
meter un caché de planes de ejecución para que no sea necesario usar
procedimientos almacenados, mientras tanto en otros departamentos continúan
haciendo la recomendación de usarlos para todo, sin considerar que esa
recomendación ha quedado obsoleta.

Preguntas similares