mi mail: maxi.accotto@gmail.com Es bueno usar stores Procedures? - BLOG DE MAXI ACCOTTO

BLOG DE MAXI ACCOTTO

Blog de SQLServer

Es bueno usar stores Procedures?

Bueno esta pregunta es la de muchos, aca hay varias opiniones , algunos defienden mucho a los Stores Procedures , otros nunca los usan y otros los usan en algunas ocaciones.

La idea de este post es ver para que son utiles estos objetos.

Un Store procedure no es mas que un objeto creado dentro del motor de base de datos, este objeto contiene un set de instruciones T-SQL (en el caso de SQLServer), pero para que son realmente?

Bueno, el uso de stores procedures tiene algunas ventajas, como las siguientes:

  1. Seguridad
  2. Centralizacion del codigo
  3. Performance

Seguridad: nos dan la posibilidad de no darles acceso directo a los usuarios a las tablas del sistema, sino que por medio de un Store (lo podriamos ver como un puente) dar acceso a ejecutarlo pero que el usuario no tenga acceso directos sobre las tablas, esto tiene enormes ventajas de seguridad ya que no es muy buena idea que un usuario se pueda conectar al servidor y poder hacer un select por ej sobre la tabla Customers y le muestre todos los campos o bien insertar valores como quiere.

Centralizacion del codigo: Los Stores estan dentro de la base de datos con lo cual el codigo esta centralizado, si lo tuvieramos en las aplicaciones ese codigo podria estar en mas de un lugar y seria mas complicado luego a la hora de hacer mantenimiento, por ej: agregar una columna: si manejamos Stores es muy simple poder ver cuales afectaban a la tabla modificada para poderlos tocar, de la otra manera hay que hacer un rastreo mucho mayor y mas complicado a la vez.

Performance: Depende del Store que hagamos (si hace un simple insert no veremos mucha diferencia) la performance es mayor que si ejecutamos las sentencias desde la aplicacion directamente, esto tiene una explicacion simple y es que los Stores quedan compilados y el motor de base de datos no debe calcular por cada ejecucion (a menos que se lo indiquemos) que vuelva a calcular los planes, esto hace que el proceso sea mas eficiente, si tenemos 100 usuarios que tienen codigo en su aplicacion y los tiran lo mismo hara 100 veces el mismo calculo el motor, pero si en luagar de tenerlo asi esta en un Store el quedara en cache y ademas compilado haciendo que la performance mejore.

 

Bueno estas parecen ser todas buenas noticias, pero porque mucha gente no los utiliza? bueno aqui un par de argumentos de la mayoria de esas personas:

1) Me ato a un motor de base de datos

2)No conozco tan bien T-SQL como mi lenguaje de programacion

3)No es tan poderoso T-SQL como mi lenguaje de programacion

4)Tengo que crear muchos objetos en la base de datos (minimanente 4 Stores por tabla  CRUD )

 

Bueno, esto es algo de cierto y algunas cosas que hay que analizar bien, vayamos por partes

1) Es  cierto, te atas a un motor, pero cual es el problema? con ese criterio tampoco me deberia atar a un SO, a un lenguaje de programacion, etc, etc, ademas si quiero hacer un sistema muy generico al final no terminare aprovechando lo mejor de cada tecnologia con lo cuel sere muy ineficiente, yo soy de la idea de que se debe aprovechar lo mejor de cada tecnologia y si quiero un sistema que funcione con mas de un motor de base de datos, entonces debere escribir para cada version lo mejor de cada uno, el trabajo es mas es cierto pero de calidad :)

2)Es una gran realidad, no mucha gente conoce bien TSQL, en 2000 esto era un gran problema pero en 2005 si no conoces bien TSQL y queres hacer Stores y centralizar podes hacerlos en .NET :), no es lo mas recomendado ya que CLR dentro de SQL se lo deberia usar para cuando TSQL no puede resolver lo que necesito.

3) Bueno, esta limitacion con SQL2005 ya ha sido superada, SQL2005 soporta CLR dentro con lo cual podemos programar nuestros objetos (Stores, Funciones, Tipos de datos, Triggers y funciones de agragacion) con CLR

4) Cual es el problema de tener muchos objetos? el motor no tiene problemas por eso :) ahora si la tarea es muy laboriosa entonces porque no usar algun generador de codigos ? hay muchos y hasta Free que con solo el hecho de seleccionar una Tabla genera los Stores del CRUD y si no me gustan o bien quiero mas es solamente cuestion de generar mis plantillas

 

Bueno, es un tema que siempre tendra discusion pero la verdad que yo defiendo el uso de Stores porque me da mas beneficios que desventajas, ademas esas desventajas las puedo saltear.

Me gustaria saber la opinion de ustedes, si ven alguna otra desventaja o ventaja asi la discutimos y vamos entre todos aprendiendo :) 

 

 

 

Comments

Daniel said:

muy buen artículo, gracias por explicar mejor el uso de los stores, es que a veces uno sabe que tiene que hacer algo pero no por qué o no sabe cómo explicarlo, exitos...

# June 25, 2007 10:38 AM

Leonardo Gauna said:

Excelente articulo, ahora tengo una pregunta:

- En la performance, en cuanto mejora la ejecucion de procesos, bien sea un insert, o simplemente una consulta (digamos que en porcentaje)  al implementar un Store Procedure, con respecto a ejecutar las sentencias directamente desde una aplicacion?

# November 2, 2007 8:02 AM

Fausto SanMartin said:

TIene que tambien proporcionar las desventajas como la generalizacion

# December 10, 2007 8:02 AM

Fausto SanMartin said:

Es preciso que nos de a conocer las desventajas por que no todo es coom lo pinta

# December 10, 2007 8:05 AM

Luis Espinoza said:

Holaa

antes de leer tu articulo, sabia de la fascilidad que nos brinda los SP, otra de las ventajas es que puedes invocar a un SP desde una aplicacion windows .net, aplicacion web aspx, seguramente desde versiones posteriores tambien se podran y desde otros lenguajes de programacion.

entre a tu pagina, para matar las dudas, ps esto nadie me lo explico, pero con la experiencia, lo deduci.

lo que quisiera saber es, si se puede hacer lo mismo con MySQL

saludos

Luis Espinoza

luis_eclaro@hotmail.com

Lima-Peru

# August 11, 2009 12:01 PM
Leave a Comment

(required) 

(required) 

(optional)

(required)