Acceso a Datos (Mejores practicas)

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.

Alberto,

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.

Cuando hablas de versiones modernas de SQL Server, ¿te refieres a 2005?

Buena recomendación de alberto para los que ocupan SQL Server, ojo que como
práctica general de acceso a datos hay que considerar el motor

Saludos

"Alberto Poblacion"
escribió en el mensaje news:

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.

"Mauricio Correa" wrote in message
news:%23BCqv%

Cuando hablas de versiones modernas de SQL Server, ¿te refieres a 2005?

En la versión 2000 ya existía el caché de planes, aunque el de la
versión 2005 es más sofisticado:

http://www.microsoft.com/technet/pr...ecomp.mspx

No estoy de acuerdo Alberto. Los procedimientos almacenados no se han
quedado obsoletos y siguen tendiendo ventajas frente a instrucciones SQL
lanzadas por la aplicación por muy sencillas que sean.

Es cierto que los planes de ejecución para consultas parametrizadas se
guardan igual que los de los procedimientos almacenados, esto ya era así
desde la versión 7.0 de SQL Server. Y en este sentido, no hay diferencia de
rendimiento entre usar consultas parametrizadas o procedimientos almacenados
para consultas sencillas. Si el código es relativamente grande, usar
procedimientos almacenados reduce el tráfico de red.

Sin embargo, los procedimientos almacenados siguen teniendo ventajas de
seguridad. Por ejemplo puedes crear un procedimiento para eliminar un
registro y dar permiso de ejecución de este procedimiento a los usuarios.
Así los usuarios pueden eliminar registros, pero DE UNO EN UNO. Por otra
parte si utilizas la instrucción DELETE directamente desde la aplicación
tienes que dar permiso de delete sobre la tabla a los usuarios, con lo que
un usurario PUEDE ELIMINAR TODOS LOS REGISTROS DE LA TABLA DE UNA SOLA VEZ,
usando la instrucción DELETE FROM LaTabla sin cláusula WHERE. Lo mismo
ocurre para insert y update.


Otra ventaja de los procedimientos almacenados es la encapsulación. Mediante
procedimientos almacenados defines un interfaz entre la aplicación y la base
de datos que oculta los detalles de la base de datos, el modelo de datos,
las tablas, etc. Esto permite hacer modificaciones en las tablas sin afectar
a la aplicación. Por ejemplo un DBA podría decidir particionar
verticalmente una tabla porque muchos de los campos son prácticamente de
solo lectura. O podría decidir desnormalizar ciertas tablas para aumentar el
rendimiento de ciertas consultas. El DBA modificaría la estructura de las
tablas y el código de los procedimientos almacenados y la aplicación no se
enteraría. Un DBA también podría modificar los procedimientos almacenados
para incluir hints en las instrucciones SQL con el fin de resolver ciertos
problemas o aumentar el rendimiento. Si las instrucciones SQL las manda
directamente la aplicación, un DBA no puede hacer nada con ellas, tiene
atadas las manos porque necesitaría modificar el código de la aplicación al
normamente no tiene acceso.


Las ventajas de los procedimientos almacenados siguen vigentes y no han sido
superadas en absoluto. Quien haya dicho lo contrario se equivoca de plano y
nunca ha sido DBA ni nunca ha ido a optimizar una aplicación en producción.

Saludos:

Jesús López
www.solidqualitylearning.com





"Alberto Poblacion"
escribió en el mensaje news:

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.

Excelentes opiniones...

La verdad, yo estoy de acuerdo con la encapsulación de todo en stored
procedures, sin embargo, por rapidez (y presión) en el desarrollo de
aplicaciones a veces se opta por colocar las sentencias SQL en el
codigo.

Como soy desarrollador y no me considero ni de cerca un DBA (Aunque
puedo hacer cualquier stored procedure), no entiendo el concepto de
"Planes de Ejecución de SQL Server", ni sus atributos ni propiedades.

Gracias por sus opiniones.. y ojalá existiera un consenso sobre el
tema..

Saludos