Store Procedures

Los Stored Procedures, de una forma mas sencilla, te pueden ayudar a
controlar tareas, generar procesos, informes y muchas cosas mas dentro de
una base de datos, no es lo mismo (jajaj, y no es la cancion de Alejandro
Sanz).. un select * from tabla, que hacer un stored procedure especificando
los campos que necesitas ya que si tienes por ejemplo 1,000,000 de registros
en una tabla, el tiempo de respuesta sera mucho mas que si unicamente
obtienes los campos necesarios, claro que este select sencillo podrias
realizarlo con una vista, sinembargo, los sp te dan la facilidad de
establecerles parametreos, y dentro del mismo poder colocar fragmentos de
codigos para procesos especificos, los cuales no podrias realizar en una
vista. en www.portalsql.com podras encontrar mas informacion sobre stored
procedures, si quieres ampliarte de la explicacion de los BOL.



Fernando España
Gerente Informatica
Alta Tecnologia en Informatica S.A.
www.atisa.com.gt
7a. calle 4-34 Zona 10
Guatemala Centro America
PBX: (502) 3620005

Email:

****************************************

"Ariel" escribió en el mensaje
news:111ed01c3f56d$9d439c00$

En que casos es recomendable usar store procedures, no es
lo mismo hacer en la aplicacion "SELECT * FROM tabla" que
crearlo en un store procedure?
Gracias
:)

Hola:
Los 3 casos mas simples:
a) Cuando tienes que dar mantenimiento a los sistemas. (Ejemplo agregar
una columna a una Tabla, o dividir una Tabla en 2). El ambos casos es
necesaria que cambies codigo en la aplicacion si hacer SELECT *, mientras
que el procedimiento puede cambiarse y la aplicacion no notara la diferencia
del esquema de las tablas.
b) Cuando tienes que dar seguridad a la aplicacion. Si la aplicacion
hace SELECT *, requerira acceso a las Tablas (Permisos), y podra usar
cualquier programa para usar dicha tabla (Excel, Access, etc). mientras que
via Procedimiento, primero no es tan facil, y segundo queda limitado por lo
que el procedimiento autoriza a hacer.
c) Desempeno: Cuando el SELECT es complejo, se minimiza el trafico y se
optimizan las consultas al quedar compilados los planes de ejecucion.
La razones entonces son: Mantenimiento, Seguridad y Desempeno!!!
La parte negativa es que requieren una "capa" mas de desarrollo (hacen
mas lento la construccion del software) y que normalmente quedan en
"dialecto" del proveedor de la base de datos, lo que hace mas dificil la
migracion de aplicaciones.

Saludos,

Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Ariel escribio:

En que casos es recomendable usar store procedures, no es
lo mismo hacer en la aplicacion "SELECT * FROM tabla" que
crearlo en un store procedure?
Gracias
:)

Porque el uso de Stores?

bueno hay muchas razones para usarlos de verdad, como debe ser que casi
todos los motores tienen Stores Procedures.

Entre sus ventajas hay una que es muy interesante de resaltar:

El Store se ejecuta en el Servidor y este se compila por lo cual la
velocidad es muy distinta a la de un Select, ni hablar si por ejemplo el
Store adentro no solo hace Select sino que insert y otras cosas hacia las
tablas de dicho motor, como veras al procesarlo todo ahi y ni enviando
sintrucciones desde la aplicacion (seria la otra alternativa) el trafico de
la red disminuye considerablemente y el tiempo de respuesta tambien.

Hay algunos que usan los Stores para no dar acceso directo a las tablas, yo
particularmente no los uso para ellos ya que los Roles de aplicacion me han
dado mejores resultados de verdad.

Ahora con esto no quiere decir que cualquier Select debe ser un Store,
quizas no convenga y sea mas prudente una vista por ej, cada caso se debe
estudiar muy bien en particular.

Aca han mencionado que los Stores pueden usan parametros y que serian mas
practicos que una vista en algunos casos, yo particularmente vi que en Sql2k
para hacer lo que se llama Vistas parametrizadas lo mejor es usar funciones
definidas de Usuario.

Tambien es importante (creo que donde mas se nota hoy dia) el uso de los
Store pero para procesar lago mas que un Select, te doy un ejemplo:

en la empresa que trabajo tenemos un soft ERP donde este Genera Ordenes de
trabajo de produccion (este proceso lo hace la aplicacion), bien por medio
de un Store se pudo lograr dicha tarea la cual solo se le pasan muy pocos
parametros y no te das una idea la diferencia de velocidad que hay cuando se
ejecuta ese Store contra lo que hace la aplicacion en si.
Ni hablar que cualquier modificacion se hace en el Store y si no cambiaron
los parametros de entrada en la aplicacion cliente no se toca nada de nada,
ni tampoco hay que ir sacando usuarios y todo ello. Claro esto te sujetara
al motor en si que trabajas, si piensas que tu aplicacion debe trabajar con
mas de un motor tampoco es problema, por ej:
Los stores se llamaran igual, lo que cambiara es el codigo de los mismos,
esto para mi es muho mejor que andar haciendolo en la aplicacion.

Esto son solo alguna de las cosas interesantes de los Stores como para
agregar a lo que han comentado aqui.


Salu2 enormes

Maximiliano Damian Accotto

Fundicion San Cayetano S.A.
Gerente de IT
Buenos Aires - Argentina
-
Desarrollador 3 estrellas
http://www.microsoft.com/spanish/ms...efault.asp
-
(maxi_accotto[arroba]speedy.com.ar)
MSN:
-

"Ariel" escribió en el mensaje
news:111ed01c3f56d$9d439c00$

En que casos es recomendable usar store procedures, no es
lo mismo hacer en la aplicacion "SELECT * FROM tabla" que
crearlo en un store procedure?
Gracias
:)