Procedimientos Almacenados vs Consultas en Codigo

maccgeo #1 Nov '13

Hola, llevo desarrollando software un tiempo ya (PHP + Codeigniter en su mayoría) y siempre al momento de diseñar la arquitectura me decantaba por colocar las consultas dentro del código.

La pregunta viene porque ahora estoy en una empresa que tiene contrato con un banco y dentro de sus estándares está el uso de C# y Procedimientos Almacenados y ahora que estoy emprendiendo un proyecto en solitario y me asalta esa duda ¿Cual es lo más óptimo Procedimientos Almacenados o Consultas en Código?

Gracias.

bLero #2 Nov '13

Los procedimientos almacenados son mucho más rápidos. Están dentro de la propia capa del SGBD, las consultas no tienen que pasar a través de un conector (ODBC / JDBC) y traducirse, simplemente la llamada al procedimiento y el retorno de resultados, y eso si deben retornar algo.

Podríamos ver a los procedimientos almacenados como un lenguaje de consultas de bajo nivel. Son más rápidos, tienes mayor control sobre las operaciones y transacciones...

2 3 respuestas

PinVa #3 Nov '13

#1 las consultas en código son mas pesadas, totalmente de acuerdo con #2

eXtreM3 #4 Nov '13

#2 y también ofrecen mayor seguridad? Al estar todo del lado del servidor, llamarse e interpretarse en el SGBD...

zoeshadow #5 Nov '13

Ya que todos habéis comentado las ventajas, comento los contras que se me han ocurrido de primeras:

Tienes la mayoría de la lógica de negocio atada a la BD en la que hayas decidido hacer los procedimientos, si un día necesitas cambiar la BD no podrás hacerlo sin tener que reescribir la mayoría de tu aplicación.
Obligas a los desarrolladores a conocer dos lenguajes.
La velocidad de desarrollo se verá afectada negativamente, como han dicho, los procedimientos almacenados se pueden considerar de más bajo nivel y como tal, mejoran el rendimiento a cambio de tiempo de desarrollo

2 2 respuestas

PinVa #6 Nov '13

#5 Si los desarrolladores no pueden aprender un lenguaje nuevo tienen un gran problema...

1 1 respuesta

zoeshadow #7 Nov '13

#6 No es cosa de no poder, es de los contras que ello puede llegar a suponer.

El que en un proyecto se usen 2 o más lenguajes incrementa la barrera a la que se enfrenta la gente nueva que entra al proyecto, dificulta la contratación de nuevos miembros del equipo, y suele provocar que se escriba código poco idiomático ( véase escribir Javascript como si fuese Java y luego quejarse de que es una mierda, que es lo que suele pasar cuando desarrolladores Java escriben Javascript ).

A mi modo de ver lo mejor es crear un sistema mixto, empezar escribiendo todas las consultas en SQL normal y luego si fuese necesario pasar a procesos almacenados las querys que mas tiempo se estén llevando.

1 1 respuesta

maccgeo #8 Nov '13

#2 Bueno entiendo el punto fuerte que es la velocidad pero aún tengo preguntas.

1.- ¿Es necesario aplicar SPs para el desarrollo de todo el sistema? Porque a mi parecer colocar

select campo1, campo2, campo3 from tabla1 where campo1 = 1

seria innecesario, y pongo select como podría poner insert, update , delete simples.

2.- ¿Por standart de codificación tendría que ser todo SPs?

Saludos

2 respuestas

Spacelord #9 Nov '13

#7 De todas formas, si te contratan para un proyecto de... no sé, Java sobre Oracle, por ejemplo, ¿no se supone que tienes que conocer Java y PL/SQL? Tanto si usas los SPs de PL/SQL como si hardcodeas las queries en el programa y usas ODBC vas a tener que conocer ambos lenguajes para trabajar en ese proyecto, ¿no?

No sé si me explico, es tarde y ya no carburo muy bien. XD

D10X #10 Nov '13

#5 Esos problemas los vas a tener aunque no uses procedimientos de BD.

Si sabes tirar consultas, sabes hacer un procedimiento almacenado.

Ya sólo por la posibilidad de cambiar la consulta en caliente, merece la pena tirar de procedures.

Soltrac #11 Nov '13 MV Wizard

#8 Yo para consultas únicas no lo uso, pero imagina un proceso que necesitas escribir varias tablas, leer de otras, etc.

En ese caso te va a ser muy útil y sobre todo más rápido que abrir una transacción, escribir todas las sentencias y hacer el commit.

1 respuesta

bLero #12 Nov '13

#8 En realidad los procedimientos almacenados, tal y como dije #11, están más orientados a procesos que a consultas, y suelen englobar varias instrucciones.

Por ejemplo:

Tienes una tienda de ropa online, y en un momento dado quieres generar la facturación de un periodo determinado. Puedes liarte a lanzar consultas desde tu aplicación e ir procesando los datos que luego los insertarás en una nueva tabla (p.e facturas), o puedes realizar una llamada a un procedimiento que haga todo eso desde la capa de la base de datos, lo cual será mucho más rápido, seguro, y además te permitirá que también puedas generar facturas desde otro programa (p.e un panel de administración de escritorio), simplemente volviendo a llamar al mismo procedimiento.

Procedimientos Almacenados vs Consultas en Codigo

Usuarios habituales

Tags