none
cuantos select insert update puedo tener dentro de un mismo store procedure RRS feed

  • Pregunta

  • hola aca con una pregunta.. es que quisiera saber en cuestion de rendimiento

    cuantas ejecuciones de select , insert update puedo tener dentro de unmismo procedure.

    create procedure xxxx

    as

    select *  from tablaba

    insert into tablaba

    update tablaba

    insert into tablab2

    update tablab2

    select *  from tablab2

    e visto.. mucho de estos procedures..  ya realizados por otros.. pero quiero optimizarlos...


    QUIERO MATAR ESTA DUDA ... ANTES QUE EL MUNDO DEJE DE EXISTIR..

    lunes, 26 de enero de 2015 1:08

Respuestas

  • Definitivamente estos debates siempre son amplios. Bajo mi corta experiencia veo a las bases de datos como contenedores de datos y administradores de las reglas que permitirán mantener los datos de manera consistente, coherente, segura, etc. etc. He visto implementar reglas de negocio en procedimientos almacenados, check constrains, triggers; no lo veo correcto y sustento los dicho por dos motivos:

    1. Ante el mantenimiento de la aplicación, tener regado las reglas tanto en la aplicación como en objetos de base de datos ya genera confusión y doble tarea al tener que revisar y hacer cambios según el lugar donde se haya hecho la implementación. Dicen que tenerlo en la base de datos evita el deployment, quizá este sustento funcionaba en aplicaciones de escritorio pero en la web no es una ventaja.
    2. En caso se decida migrar a un gestor de base de datos distinto. La aplicación sólo deberá de cambiar el proveedor de base de datos además de escribir los procedimientos base. Sí escribiste lógica en objetos de base de datos deberás migrar además dicha lógica.
    lunes, 26 de enero de 2015 5:25

Todas las respuestas

  • Hola,

    El tema del rendimiento no pasa por la cantidad de sentencias DML que encapsules, sino por lo que hacen estas instrucciones y como lo hacen. Puedes tener una sola sentencia SELECT que maneja cursores innecesariamente o búsquedas criticas  por columnas no indexadas, etc y definitivamente atentarás contra el performance en tiempos de respuesta.

    Los procedimientos como cualquier bloque de código debería estar especializado en una determinada acción. Es decir, si tienes una tabla [Cliente] deberías tener un procedimiento que inserte otro que actualice y otro que elimine, ello ayudará a encapsular funcionalidad con una sola responsabilidad y además ayudará al mantenimiento. He visto procedimientos que dentro hacen la inserción, actualización y eliminación y que la ejecución de una determinada acción la define un parámetro, me parece incorrecto, innecesario, confuso, poco legible , etc.

    Apuntando a tu pregunta, puedes tener la cantidad de instrucciones que desees y definitivamente hay procedimientos donde involucrarás varias sentencias DML como el caso de las cabecera-detalles donde se trata de una única transacción, lo único que sugiero es mucho criterio al definir la responsabilidad única que tendrá el procedimiento.

    Finalmente, la abstracción de una regla no la debería definir un procedimiento, sino la aplicación. Por ejemplo, si tuvieses la regla de que al registrar un cliente se debe de crear un registro en la tabla [Plan de visitas] y actualizar la tabla [Seguimiento de clientes] al estado "captado", no es algo que deba abstraerlo en su totalidad el procedimiento, sino que la aplicación deberá manejar esa regla y dependiendo de las condiciones invocará al procedimiento de insertar cliente, luego al procedimiento de insertar plan de visitas y finalmente al procedimiento de actualizar seguimiento de clientes, ¿te imaginas si el procedimiento de insertar cliente tendría otras sentencias dentro? no podríamos reutilizarlo.

    Si la solución propuesta atendió su consulta no olvide marcarla como respuesta.


    Willams Morales P.
    Arequipa - Perú

    • Propuesto como respuesta Jesús López lunes, 26 de enero de 2015 13:18
    lunes, 26 de enero de 2015 4:10
  • sobre este punto :

    Finalmente, la abstracción de una regla no la debería definir un procedimiento, sino la aplicación. Por ejemplo, si tuvieses la regla de que al registrar un cliente se debe de crear un registro en la tabla [Plan de visitas] y actualizar la tabla [Seguimiento de clientes] al estado "captado", no es algo que deba abstraerlo en su totalidad el procedimiento, sino que la aplicación deberá manejar esa regla y dependiendo de las condiciones invocará al procedimiento de insertar cliente, luego al procedimiento de insertar plan de visitas y finalmente al procedimiento de actualizar seguimiento de clientes, ¿te imaginas si el procedimiento de insertar cliente tendría otras sentencias dentro? no podríamos reutilizarlo.

    es a  lo que me refiero...   segun lo que dices no es correcto o no deberia definirse ..   en un solo procedimiento.

    mmm  pero como respuesta en eejecucion... (dejando de lado la reutilizacion)

    que es mas rapido..

    llamar  3 procedures .. una por una desde mi aplicacion

    o  que estas 3 sentencias se ejecuten en un solo procedure.. ?


    QUIERO MATAR ESTA DUDA ... ANTES QUE EL MUNDO DEJE DE EXISTIR..

    lunes, 26 de enero de 2015 4:35
  • Hola,

    Definitivamente es más rápido que se ejecute todo desde un procedimiento porque evitas las llamadas a la base de datos, aún así no es un tiempo considerable si es que tienes configurado el pooling de conexiones. Creo que ganas mas en legibilidad y reutilización que milisegundos de diferencia.

    lunes, 26 de enero de 2015 4:41
  • No quisiera ahondar mucho en el punto, ya que es tema un poco largo de discutir sobre este tema pero desde el punto de performance es normalmente mejor un procedimiento almacenado (y el mismo para seguridad), como bien indica Williams, aunque existe un debate muy candente sobre cual es el mejor o quien realmente deberia de controlar esto, si la base de datos (dba) o el area de desarrollo (programadores).

    Esto te diria que es algo que debe de definir el lider de proyecto de acuerdo a las necesidades del cliente y el area que mantendra el mantenimiento de la aplicación.

    lunes, 26 de enero de 2015 5:05
  • Definitivamente estos debates siempre son amplios. Bajo mi corta experiencia veo a las bases de datos como contenedores de datos y administradores de las reglas que permitirán mantener los datos de manera consistente, coherente, segura, etc. etc. He visto implementar reglas de negocio en procedimientos almacenados, check constrains, triggers; no lo veo correcto y sustento los dicho por dos motivos:

    1. Ante el mantenimiento de la aplicación, tener regado las reglas tanto en la aplicación como en objetos de base de datos ya genera confusión y doble tarea al tener que revisar y hacer cambios según el lugar donde se haya hecho la implementación. Dicen que tenerlo en la base de datos evita el deployment, quizá este sustento funcionaba en aplicaciones de escritorio pero en la web no es una ventaja.
    2. En caso se decida migrar a un gestor de base de datos distinto. La aplicación sólo deberá de cambiar el proveedor de base de datos además de escribir los procedimientos base. Sí escribiste lógica en objetos de base de datos deberás migrar además dicha lógica.
    lunes, 26 de enero de 2015 5:25
  • Hola.

    En principio, un procedimiento almacenado representa un conjunto de instrucciones, generalmente con algo en común, que permite encapsular funcionalidad requerida, bien sea por manipulación de la base de datos o por lógica de negocio.

    Partiendo de lo anterior, lo que si hay que tener en cuenta en los procedimientos almacenados es el manejo de excepciones y que sea óptimo en términos de plan de ejecución, en cuanto a rendimiento se refiere. Que sean pocas o muchas instrucciones T-SQL, cada quien definirá de acuerdo con lo que se quiere.

    Hay mucha documentación sobre el particular, incluyendo un artículo de Pinal Dave sobre aspectos esenciales en términos de desempeño que yo he adoptado y a partir de ahí mejoro con base en ejecuciones y análisis realizados, SQL SERVER – Stored Procedure Optimization Tips – Best Practices.

    Saludos,


    Guillermo Taylor F.
    IT Pro & Xbox gamer
    My blog

    lunes, 26 de enero de 2015 12:54