none
ventajas de usar Procedimientos Almacendos?

    General discussion

  • en internet se pueden encontrar muchas entradas sobre esto: Procedimientos Almacenados contra consultas, o Stored Procedure Advantages, entre otras.

    Pero me gustaría iniciar aquí una lista de ventajas (y desventajas si alguno les ha encontrado), sobre los procedimientos almacenados de acuerdo a la experiencia que tiene con estos.

    Mi lista de vetanajas:
    1. Ideal para un modelo en capas. Aunque esto es mas un escenario que una ventaja, si estas usando un modelo en capas, usar store procedures, te ayuda a marcar la división de las capas.
    2. Qué sistemas transaccionales (de los buenos Big Smile) (de SQL), se hacen sin usar StoreProcedures?, creo que no he visto ninguno, aprender hacerlos desde que hacemos nuestro primer ejemplo o sistema, nos hará más fácil la adaptación. La ventaja de este item sería: el uso desde simple ejemplos te hace más la adaptación para tu futuro profesional.
    3. Hace el mantenimiento y las actualizaciones más fácil. Imaginen que en un periodo de pruebas se olvidaron un hardcode, (WHERE compania=1), y lo tiene como query en C# Tongue Tied, compilar todo sólo para quitar ese hardCode?, si tuvieramos StoreProcedure sólo sería hacer el cambio en el store procedure.
    4. Permite hacer optimizaciones en la base de datos sin mucho esfuerzo (casi igual a la anterior), con todos los querys en el código, imaginen como sería la tarea de optimización?
    5. Aprendes más T-SQL, por que en C# por ahi que le sacas la vuelta con un código, pero si haces store procedures, tienes que hacer T-SQL si o si. (En este punto imaginemos que no existe SQL-CLR).
    Esas son las que se vienen a mi mente en este momento, pero seguro que ustedes tienen más....

    P.D.: Me gustaría que este sea "el post" sobre las ventajas de store procedures, asi si alguién tiene un duda sobre por que usar esto, lo reenviemos aquí Smile.

    Saludos,
    Monday, January 14, 2008 2:05 PM

All replies

  • Déjame hacer de abogado del diablo.... Wink

     

    Desventaja: PORTABILIDAD

     

    En proyectos dónde podemos hacer instalaciones contra diferentes servidores de bases de datos (MySQL, Oracle, SQL Server...) debemos mantener versiones diferentes de los SP para cada tipo de servidor ya que las sintaxis empleadas en el SQL que implementan cada uno de ellos difiere aunque sea en pequeños detalles.

     

    Es cierto que los generadores de código amortiguan dicho problema... pero bueno, así meto un poco de polémica sana, no? Stick out tongue

     

    Salud y suerte!

     

     

    Monday, January 14, 2008 2:47 PM
  • Hola,

     

    a mi siempre me gusta llevarle la contraria a toni

     

    creo que lo mas importante de los procedimientos almacenados es LA SEGURIDAD

     

    como principal caracteristica invalidas los ataques con Inyeccion de Sql (aunque esto ya se puede hacer hoy en dia usando parametros)

     

    tambien puedes crear usuarios especificos para ejecucion de procedimientos y de esta manera no dejas expuesta el resto de la base de datos.

     

    de todas maneras si quieres saber mas te recomiendo el programa de capacitacion online gratuito Net Protector

     

    http://www.mslatam.com/latam/msdn/comunidad/netprotector/

     

    un saludo.

    Monday, January 14, 2008 3:14 PM
  • EHHH!!!! Yo no he dicho que no recomiende el uso de SP!!! De hecho yo los uso. Tan sólo que no todo son ventajas... Wink

     

    Monday, January 14, 2008 3:17 PM
  • mas EHHHHHHHH para ti jajajaja

     

    que yo no he dicho que no los recomiendes... solo que como me gusta llevarte la contraria me tocaba defenderlos.

     

    obviamente no todo van a ser ventajas, si asi fuera todo el mundo los usaria

     

    hoy te la paso que andas muy sensible

     

    un saludo.

    Monday, January 14, 2008 3:20 PM
  •  Toni Recio Escribió:

     

    Desventaja: PORTABILIDAD

     

    En proyectos dónde podemos hacer instalaciones contra diferentes servidores de bases de datos (MySQL, Oracle, SQL Server...) debemos mantener versiones diferentes de los SP para cada tipo de servidor ya que las sintaxis empleadas en el SQL que implementan cada uno de ellos difiere aunque sea en pequeños detalles.

     



    Toni cuantos sistemas has visto así?, y que escenarios eran?

    Saludos,
    Monday, January 14, 2008 5:03 PM
  •  Javier Conesa Escribió:

     

    obviamente no todo van a ser ventajas, si asi fuera todo el mundo los usaria

     



    Javier en que caso a alguién que esta haciendo una aplicación le recomendarías que no use SPs?

    Saludos,
    Monday, January 14, 2008 5:05 PM
  •  Javier Conesa Escribió:

    mas EHHHHHHHH para ti jajajaja

     

    que yo no he dicho que no los recomiendes... solo que como me gusta llevarte la contraria me tocaba defenderlos.

     

    obviamente no todo van a ser ventajas, si asi fuera todo el mundo los usaria

     

    hoy te la paso que andas muy sensible

     

    un saludo.

     

    Hola, a ver si puedo contribuir,

     

    Los uso actualmente y en proyectos anteriores no los he usado. He estado de los dos bandos por así decirlo.

     

    Así que coincido 100% con Toni y con Javier, y a su vez voy a dejar una ventaja y una desventaja:

     

    Ventaja:

    • los SP se encuentran precompilados en SQL Server, lo que hace que la ejecución de un SP  en el motor sea mas performante contra la misma consulta, insert, update o delete, embebido en nuestra aplicación.

    Desventaja:

    • la utilización de SP es menos productiva en horas desarrollo, cuando tenemos un framework de proyecto que embebe las consultas directamente a partir de la definición de una clase, podría ser el caso de framework propietario ORM o bien de los conocidos entre ellos NHibernet.

    Saludos,

     

    Monday, January 14, 2008 5:20 PM
  • Hola,

     

    sinceramente??

     

    yo nunca recomendaria no usarlos.

     

    sin embargo entiendo algunas razones por las cuales he tenido que embeber el codigo dentro de la aplicacion como puedan ser ambitos con una fuerte logica de negocio, donde la creacion de procedimientos que se ajusten al modelo es demasiado complicada y no se disponga de un experto o persona encargada en exclusiva al tema. En esos casos concretos el desarrollo es mas rapido prescidiento de procedimientos almacenados.

     

    pero vamos es una opinion

     

    un saludo.

    Monday, January 14, 2008 5:49 PM
  • Voy a intentar aportar mi punto de vista..

     

    > El tema de la portabilidad no lo veo como ventaja ni desventaja. Habitualmente siempre que se inicia una aplicación se quiere que sea compatible con todos los sistemas de base de datos pero realmente pocas veces es necesario. Aunque no uses procedimiento en muchos casos te ves obligado a hacer sentencias SQL con características particulares de una determinada base de datos casi siempre con el objetivo de rendimiento. Por otro lado, si analizas los diferencias, por ejemplo, entre SQL Server y Oracle las diferencias no son pocas.....Por eso, al final hagas como lo hagas hacer un único juego de sentencias es muy muy complicado y como he comentado no siempre necesario.

    Pero si realmente hay que hacerlo compatible hacer procedimientos suele costar más.

     

    > Sobre el tema de que usar un procedimiento almacenado ofrece un mayor rendimiento que usar una sentencia SQL dentro del código es más óptimo debo comentar que considero que no es cierto. Una sentencia usando parámetros tipados puede ofrecer el mismo rendimiento cuando el plan de ejecución está en base de datos. Eso sí, el plan de ejecución de un procedimiento puede permanecer más tiempo que el plan de ejecución de una sentencia SQL.

     

    > El procesamiento de un procedimiento se hace en el servidor de base de datos, no en el cliente.

     

    > Se carga menos la red usando procedimientos.

     

    > A nivel de seguridad los procedimientos son una mejor opción.

     

    > El hacer procedimientos reduce la complejidad de la lógica de la aplicación. Muchas veces tener que incluir las sentencias en el código suele enguarrar él código y hacerlo menos legible.

     

    > Usar procedimientos suele ser una buena opción pero soy totalmente contrario a incluir lógica de negocio en los procedimientos....pero como nadie de todo impide, puede ser muy fácil caer en la tentación y hacerlo, con lo que incluyes la lógica de negocio en capas diferentes.

     

    > Sea cual sea la opción elegida hay que intentar mantener el criterio a lo largo de la aplicación. Si usar procedimientos, usa procedimientos.

     

    Bueno, espero que haya podido aportar algo.

    Monday, January 14, 2008 7:58 PM
  •  starrillo Escribió:


    Toni cuantos sistemas has visto así?, y que escenarios eran?

    Saludos,

     

    La verdad es que he visto varios escenarios de ésta índole, sobretodo cuando se generan productos paar el mercado en lugar de hacer programación a medida, a petición de las necesidades de un cliente.

     

    Si por ejemplo queremos poner en el mercado un software de gestión de almacenes es muy probable que tengamos que integrarnos con la estructura de BBDD de nuestros clientes, y sobretodo, nos podemos encontrar que el cliente no quiere pagar licencias de otro servidor de BBDD's o pagar a otro administrador.

     

    En todo el caso, lo más importante en este sentido yo creo que está de puertas adentro. Es vital que una empresa de software pueda decir que todos sus desarrolladores programan "igual". Ahora en mi empresa podemos generar automáticamente desde el propio VS los SP's para Oracle, MySQL y SQL Server, de modo que los desarrolladores pueden abstraerse, pero estamos obligados a que cualquier mejora que introduzcamos debemos hacerla teniendo en cuenta estas tres versiones.

     

    En resumen; SÍ a los SP's... pero alguna desventaja habían que tener... Wink

    Monday, January 14, 2008 8:26 PM
  • Hola Toni,

     

    Os cuento mi caso personal por aportar un punto de vista. He trabajado en productos que podemos llamar de gestión que no son a medida para ninguna empresa.

     

    En un principio también partimos de la base de que podría ser interesante soportar varias base de datos, SQL Server y Oracle principalmente, ya que cada cliente podría tener sistemas de base de datos diferentes.

     

    Por temas de rendimiento habitualmente te ves obligado a usar temas específicos de un motor u otro...así que no puedes hacer un único juego de sentencias. Primaba sacar el máximo rendimiento a la base de datos que hacer un código compatible.

     

    A esto se le suma que si desde el principio no haces un estudio de compatibilidad olvídate después. Las diferencias, por ejemplo entre SQL Server y Oracle puede parece pocas, pero las hay y bastantes.

     

    A la hora de ir al cliente no hemos tenido nunca ningún problema. Con clientes pequeños siempre hemos usado la versión MSDE y en cliente más grandes hemos usado SQL Server. Incluso clientes que tenían Oracle han usado sin problema SQL Server.....en alguna ocasión nos lo han pedido como un tema deseable, pero en ningún caso me consta que haya sido un causa para no vender el producto que no soportemos otro motor que no sea SQL Server.

     

    Este es mi caso, aunque claro está, en que otros casos si será necesario mantener esa compatibilidad que comentas.

    Monday, January 14, 2008 10:03 PM
  • Completamente de acuerdo con Ibon,

     

    Es por ello que optamos por la generación de código automática para el acceso a datos. Creamos una capa de acceso a datos a partir de la estructura de datos de la BBDD a partir de plantillas concretas de cada una de las bases de datos que buscamos soportar, y de momento los resultados son bastante buenos.

     

    Supongo que cada "maestrillo" tiene su "librillo", no?

    Wink

     

    Monday, January 14, 2008 10:08 PM
  • Claro está, no hay una única solución...cada problema es diferente y por tanto la solución

     

    Un saludo!!
    Monday, January 14, 2008 10:21 PM
  •  Ibon Landa Escribió:

     

    > Usar procedimientos suele ser una buena opción pero soy totalmente contrario a incluir lógica de negocio en los procedimientos....pero como nadie de todo impide, puede ser muy fácil caer en la tentación y hacerlo, con lo que incluyes la lógica de negocio en capas diferentes.


     



    Ibon, hace poco estuve en ese escenario, digamos que tenía que generar unos registros a partir de otras 5 o 6 tablas, con algunos datos iniciales y la data de esas tablas generaba los registros. Mi preocupación era no tener que estar iendo constamente a la BD desde el cliente (teoría que viajar menos a una base de datos tiene mejor rendimiento), fácilmente podía enviarle unos 4 datos iniciales, y en un procedimiento y con las tablas, hacer todo el trabajillo...


    tu propuesta para estos escenarios es hacerlo todo en el cliente, y estar iendo y viniendo de la BD, cuando todo lo podrías hacer en un SP?


    Saludos,

    Tuesday, January 15, 2008 2:32 AM
  • Ofrecer una misma regla siempre es complicado. Como se suele decir no hay balas de plata. Yo considero que es importante saber los pros y contras de cada situación y cuando se toma la decisión saber por qué se toma. El que hace y conoce la aplicación también es el que mejor puede tomar la decisión si conoce todos los condicionantes.

     

    Como normal general a mí no me gusta meter nada de lógica de negocio en los procedimiento almacenados y prefiero ir a la base de datos, coger los datos y luego hacer la lógica que considere...lógica relacionada con la aplicación.

     

    En el caso que comentas, por lo que entendido, parece más un tema de rendimiento y el procesamiento que haces es de cara a devolver los datos de una manera más rápida y más óptima, por lo que no considero que eso puede considerarse lógica de negocio y podría hacerse perfectamente en el SP. Cierto es que por mejorar el rendimiento a veces se toman decisiones que se saltan la regla general, como la típica de desnormalizar las tablas.

     

    Tuesday, January 15, 2008 12:40 PM
  • Estoy totalmente de acuerdo, nuestro trabajo sería mucho más fácil si la misma solución o análisis nos sirviera para todos los problemas o tipos de aplicación.

     

    Saludos.

    Tuesday, January 15, 2008 4:12 PM
  • En la siguiente direccion pueden leer algo interesante al respecto.

    Chaooo

    http://www.rodrigosalinas.cl/?page_id=52

     

    Wednesday, January 16, 2008 8:42 PM
  • Una excelente entrada sobre el comportamiento del plan de ejecución, de Store Procedures vs Queries Parametrizados vs Queries simples: These Days: Un día en la vida de una consulta....

    Otra entrada desde el sitio Coding Horror:
    Stored Procedures vs. Ad-Hoc SQL.

    Saludos,
    Sunday, May 18, 2008 6:37 PM