Ventajas/Desventajas de Procedimientos Almacenados en la Web

elunicode · #1 (**permalink**) 04/09/2006, 16:31

A todos los gurús de Base de Datos, me gustaría saber cuales son las Ventajas y Desventajas de Utilizar procedimientos almacenados en un sistema web, pues pienso crear un sistema pero utilizando este tipo de Tecnología de base de datos y quisiera conocer opioniones
Gracias

Linterns · #2 (**permalink**) 05/09/2006, 08:17

VENTAJAS: acceso mas rapido, mayor velocidad de respuesta, mejor manejo de la paqueteria ya que lo tienes todo ahi.

DESVENTAJAS: se corrompoe la base de datos adios a todo el trabajo hasta el ultimo respaldo que tengas

Developer9 · #3 (**permalink**) 05/09/2006, 08:46

Cita:

Iniciado por Linterns

VENTAJAS: acceso mas rapido, mayor velocidad de respuesta, mejor manejo de la paqueteria ya que lo tienes todo ahi.

DESVENTAJAS: se corrompoe la base de datos adios a todo el trabajo hasta el ultimo respaldo que tengas

Son mas ventajas que desventajas... si ejecutamos sentencias sql estableciendo una conexion entre mi aplicación y la base por la naturaleza de la aplicación web se demorará más en relación si tan solo mandamos a ejecutar dichas sentencias en un procedimiento almacenado, sobre todo si son sentencias pesadas. Aunque tambien es verdad que la base de datos tiene mas importancia ya que existe programación dentro de ella pero se debe de tener una buena estrategia de respaldos de la misma, si ya tenemos una base de datos en producción se debe generar los script necesarios que contengan los CREATE PROCEDURE, TABLE, VIEW, FUNCTION, DATABASE, TRIGGER, USER... y todos los objetos de la base. De tal manera que si le pasa algo a la base su estructura está protegida.

Utilizar procedimientos es beneficioso ya que dicho código ya está compilado en la base de datos y se ejecuta mucho mas rápido

Mithrandir · #4 (**permalink**) 05/09/2006, 14:30

No le conozco desventajas, a menos que seas adicto al SQL generado al vuelo desde el lenguaje (ASP, PHP, ...), en cuyo caso también serás adicto a las inyecciones de SQL o supervalidaciones desde la aplicación.

Sobre perder los avances en caso de problemas... ¿que puedo decir...? ¿Que pasa si se corrompe la partición donde está el Web? Solo un buen esquema de respaldos te salvará en cualquiera de los dos casos.

elunicode · #5 (**permalink**) 05/09/2006, 16:28

Muchas gracias por sus comentarios, su ayuda me ha sido de mucha ayuda y sugerencia, pues pensaba que habría más desventajas que ventajas.

foo · #6 (**permalink**) 05/09/2006, 21:21

Cita:

Iniciado por Mithrandir

No le conozco desventajas, a menos que seas adicto al SQL generado al vuelo desde el lenguaje (ASP, PHP, ...), en cuyo caso también serás adicto a las inyecciones de SQL o supervalidaciones desde la aplicación.

el SQL generado no necesariamente implica inyecciones de SQL, la mayoria de lenguajes -que se precien de serlo- ofrecen metodos para trabajar con parametros de forma segura. Ahora bien, tampoco el uso de procedimientos almacenados indica que no se pueda hacer sql injection (recuerda que tambien en los sp se puede generar "sql al vuelo")...

por otro lado, el SQL generado es mas flexible para los O/RM, a diferencia de los procedimientos almacenados

cada esquema tiene sus ventajas y desventajas, sobre este tema se ha escrito multitud de articulos o posts en blogs...te recomiendo la lectura de http://weblogs.asp.net/fbouma/archiv.../18/38178.aspx para que no desprecies tanto al sql generado

Developer9 · #7 (**permalink**) 06/09/2006, 12:56

mmmm.... que será mas fácil, hacer un sql injection a una aplicación o a un procedimiento.

foo · #8 (**permalink**) 06/09/2006, 13:22

Cita:

Iniciado por Developer9

mmmm.... que será mas fácil, hacer un sql injection a una aplicación o a un procedimiento.

que es lo que quieres decir?

Developer9 · #9 (**permalink**) 06/09/2006, 14:17

Cita:

Iniciado por foo

que es lo que quieres decir?

Disculpas... que es mas fácil, lograr hacer sql injection a una aplicación que cree las sentencias sql en su codigo o a una aplicación que llame a un store procedure

Mithrandir · #10 (**permalink**) 06/09/2006, 14:30

Cita:

Ahora bien, tampoco el uso de procedimientos almacenados indica que no se pueda hacer sql injection (recuerda que tambien en los sp se puede generar "sql al vuelo")...

Cierto, gracias por clarificarlo.

Cita:

Disculpas... que es mas fácil, lograr hacer sql injection a una aplicación que cree las sentencias sql en su codigo o a una aplicación que llame a un store procedure

Casi cualquier sentencia SQL de aplicación sera generada al vuelo (a menos que sea estática). Mientras que para que un SP sea vulnerable al injection necesitas usar SQL dinámico dentro del propio SP (mucho más difícil de encontrar, aunque yo mismo tengo un par de ellos)

Developer9 · #11 (**permalink**) 06/09/2006, 18:17

SuPongo que la sql injection se camuflará en los parámetros del reporte... parámetros que formarán parte de algún query

Mithrandir · #12 (**permalink**) 07/09/2006, 16:23

Algo así. Por ejemplo este SP caerá como mosquita mientras que el segundo no, además de que si revisas el código, para hacer sql dinámico dentro del SP requieres de más técnica que para hacerlo desde el propio lenguaje y requiere mucho más código que hacerlo de la manera habitual de los SP...

Código:

CREATE PROCEDURE hackeame(
	@flexibilizimo_filtro NVarChar(1000) = ' campo = 1000'
)AS

DECLARE @sql NVarChar(2000)

SET @sql = 'SELECT * FROM tabla WHERE ' + @flexibilizimo_filtro

EXEC (@sql)

Código:

CREATE PROCEDURE hackeame_v2(
	@flexibilizimo_filtro Int = 1000
)AS

SELECT * FROM tabla WHERE campo = @flexibilizimo_filtro