locked
SQL: Refactorización vs. Rendimiento RRS feed

  • Pregunta

  • La cuestión es que tengo unos cuantos cientos de stored procedures con mucha lógica de negocio. De momento no puedo extraer ésta lógica, pero me he dado cuenta que muchos de ellos repiten código (tal cual copy-paste). Tengo la idea de que, para facilitar la lectura y mantenimiento de estos SPs, pudieran refactorizarse, de tal manera que en vez de tener algo así:

    CREATE PROCEDURE spHacerAlgo
    ...
    AS
    BEGIN
        ...
        SELECT @unaVariable = [consulta larga]
        ...
        SELECT @otraVariable = [otra consulta aún más larga]
        .... 
    
    END
    Pudiera tener algo así:

    CREATE PROCEDURE spHacerAlgo
    ...
    AS
    BEGIN
        ...
        EXEC spObtenerUnaVariable @unaVariable OUTPUT
        ...
        EXEC spObtenerOtraVariable @otraVariable OUTPUT
        ...
    END
    ¿Cómo se vería afectado el rendimiento de spHacerAlgo?
    laloivol
    lunes, 1 de junio de 2009 21:53

Respuestas

  • No deberias tener diferencias significativas, excepto en casos aislados.
    Sin embargo la nueva opcion, es mejor en cuanto al mantenimiento del codigo

    Si la factorización no implica que reutilizas un mismo codigo en multiples sored procedures no tiene mucho sentido hacerla.
    En el caso contrario lo haria teniendo cuidado con los parametros y como afectan el rendimiento, piensa que ahora tienes N planes posibles diferentes y luego tendras muchos menos para cada stored procedure/contexto de los que has factorizado. Sin embargo puedes usar plan guides que te ayuden en los diferentes casos si fuera necesario.


    Saludos





    Ing. Jose Mariano Alvarez http://blog.josemarianoalvarez.com/ Microsoft MVP SQLTotal Consulting Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0 (Cambia los ceros por O y saca lo que sobra) Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase
    miércoles, 3 de junio de 2009 20:05

Todas las respuestas

  • Hola, en rendimiento se vera afectado como este escrita la query y no por hacer store o no, si la query usa cursores, si no usa SARG en los where, si no tenes indices, si usar * en la lista te haran lenta la query.

    Para reutilizacion has pensado tambien la posibilidad de Funciones de usuario?
    Maxi Accotto
    lunes, 1 de junio de 2009 23:17
    Moderador
  • Si, también lo tengo contemplado, de hecho estoy investigando en qué casos es mejor uno que otro. Mi duda aquí en realidad iba más orientada a si el uso de EXEC dentro de mis SPs en vez del código completo de una función o SP puede afectar el rendimiento.
    laloivol
    martes, 2 de junio de 2009 0:02
  • En comparación con el coste de resolver la "Select", el coste de hacer una llamada al procedimiento almacenado y devolver el parámetro es insignificante. Puedes hacer un "benchmark" para probarlo, pero es prácticamente seguro que no llegarás a notar la diferencia.

    Normalmente es mucho más ventajoso el tener el código bien organizado y fácil de entender y mantener. En comparación con esto, las minúsculas e insignificantes variaciones de rendimiento que se puedan producir a causa de esta reorganización de código se consideran siempre secundarias.
    martes, 2 de junio de 2009 12:36
  • Hola no habra mucha dif de performance usando el EXEC o la query
    Maxi Accotto
    martes, 2 de junio de 2009 23:23
    Moderador
  • No deberias tener diferencias significativas, excepto en casos aislados.
    Sin embargo la nueva opcion, es mejor en cuanto al mantenimiento del codigo

    Si la factorización no implica que reutilizas un mismo codigo en multiples sored procedures no tiene mucho sentido hacerla.
    En el caso contrario lo haria teniendo cuidado con los parametros y como afectan el rendimiento, piensa que ahora tienes N planes posibles diferentes y luego tendras muchos menos para cada stored procedure/contexto de los que has factorizado. Sin embargo puedes usar plan guides que te ayuden en los diferentes casos si fuera necesario.


    Saludos





    Ing. Jose Mariano Alvarez http://blog.josemarianoalvarez.com/ Microsoft MVP SQLTotal Consulting Mi.Correo.es.j0se.marian0.alvarez@gmail.c0m.Corregirl0 (Cambia los ceros por O y saca lo que sobra) Este mensaje se proporciona tal como es, SIN GARANTIAS de ninguna clase
    miércoles, 3 de junio de 2009 20:05