none
Procedure o Programacion RRS feed

  • Debate general

  • Buenas noches, pues saben tengo una duda y quisiera que me expliquen de ello, pues el detalle es que he visto en varios códigos fuentes que no utilizan procedure, solo para algunas cosas pero mayormente cualquier inserción actualización u otro de datos lo realizan mediante programación, pero en otros casos he visto que todo lo hacen mediante procedure, claro que dentro de la programación, pero mi duda es, ¿Cuándo se programa se tiene que ser por procedure y porque? o ¿Se puede realizar todo por programación, dentro de ello estarán los query, y porque? ¿Cuál es mejor o mas seguro? espero me saquen de dudas ya que poco a poco estoy mas en esto y ya también comenzare con mis clases. Gracias
    domingo, 10 de julio de 2016 23:28

Todas las respuestas

  • Oscar Perez 1234,

    Dudo que recibas una respuesta unánime porque en este tema hay de gustos y colores. En lo personal, prefiero trabajar con procedimientos almacenados porque de esa forma separo el código sql de la aplicación, veo mas legible mi código y fácil de mantener, otra ventaja es que puedo reutilizar mis procedimientos almacenados en la aplicación y -por un tema de rendimiento- un procedimiento almacenado reutiliza un plan de ejecución almacenado en caché (ventaja que otros colegas minimizan). No imagino una consulta larga inmersa en código de la aplicación con saltos de línea y demás.

    Por otro lado, hay quienes defenderán su posición de tener escrito la consulta en la aplicación (sus sustentos no los comparto), he visto casos donde el DBA no permitía escribir procedimientos almacenados sobre la base de datos y la única manera que tenían es ejecutándolos desde la aplicación.

    Espero que la información proporcionada te haya sido de utilidad.

    domingo, 10 de julio de 2016 23:55
  • Hubo un tiempo hace años en el que se recomendaba que todo se hiciese con procedimientos almacenados, pero las razones que se daban para ello, en gran medida se han vuelto obsoletas con las versiones modernas de herramientas cliente y motor de base de datos. Veamos algunas de esas razones:

    - Evitar ataques de inyección de SQL. Se argumentaba que al pasar los parámetros al procedimiento, se evitaba la ejecución del posible código SQL escrito dentro de los parámetros, cosa que podría ocurrir si se concatenaban en la sentencia desde el cliente. Pero con la infraestructura moderna, se pueden parametrizar las sentencias en cliente, así que para esto ya no se necesitan procedimientos almacenados.

    - Guardar el plan de ejecución ya optimizado en lado servidor, asociado al procedimiento almacenado. Esto evita que la sentencia se recompile cada vez que se envía al servidor. Pero con los motores de base de datos modernos, si la sentencia está correctamente parametrizada en cliente, solo se compila una vez en el servidor y luego se guarda en el caché de procedimientos, con lo que no incurre en costo de compilación en sucesivas ejecuciones, así que una vez más esto ya no sirve como justificación para exigir los procedimientos almacenados.

    - Ajustar los permisos de acceso. Con un procedimiento, se puede pedir que se ejecute con los permisos de un usuario concreto, que no necesita ser el mismo que ejecuta la llamada. Esto permite dar a los usuarios permisos sobre el procedimiento pero no sobre las tablas a las que accede, con lo que se tiene un control más fino sobre qué pueden hacer los usuarios. Esto sigue siendo una razón válida para usar procedimientos almacenados, si es que realmente vas a aplicar ese control detallado de los permisos.

    - Evitar tráfico entre el servidor y el cliente. Por ejemplo si se leen muchos registros, se hace algo con ellos y se guarda el resultado en otra tabla, es mejor hacerlo todo en un procedimiento que se dispara con una sola llamada desde el cliente, en lugar de bombear los datos desde el servidor al cliente, hacer cálculos en el cliente, y volver a bombear los resultados hacia el servidor. Esto sigue siendo una razón válida para usar procedimientos, pero no se aplica cuando se trata de una sentencia simple que lee o graba datos, que de todas formas tienen que transportarse entre cliente y servidor.

    Al final, en la mayoría de los casos, el criterio que prima es el de la mantenibilidad de la aplicación. En los sitios en que la escritura y mantenimiento del código tiene que hacerlos el equipo de desarrolladores "cliente", suele ser más fácil seguir la ejecución del código si la sentencia es visible en lado cliente. En cambio en los sitios donde hay un DBA responsable de controlar detalladamente el funcionamiento del servidor y suficientemente bien preparado en el desarrollo con SQL, el DBA (o el desarrollador de SQL) puede dejar preparados todos los procedimientos y ponerlos a disposición de los programadores de código cliente, y para ellos es un componente externo que se da por probado (se delegan esas pruebas unitarias en el DBA), y entonces se trabaja con la base de datos exclusivamente a través de esos procedimientos.

    lunes, 11 de julio de 2016 6:28
  • Gracias por la informacion
    lunes, 11 de julio de 2016 14:40
  • Gracias Alberto
    lunes, 11 de julio de 2016 14:40