none
Duda con Select en un SP RRS feed

  • Pregunta

  • Estimados.

    En un SP que recibe 1 parametro, se hace lo siguiente:

    IF @p1 = 1
    BEGIN

    Select * from tabla where etc
    END
    ELSE
    BEGIN

    Select * from OtraTabla where etc

    END

    Casos como eso tambien para UPDATES o INSERT


    Favor les solicito sus opiniones si esta es una buena manera de hacer los SP, pues siempre he pensado que el motor actua con mejor rendimiento si fueran  2 SP distintos y el IF dejarlo al lado del cliente.

    • Es lo mismo, porque ?
    • Uno es mejor que otra opcion ? porque ?

    Saludos Cordiales.


    DBA SQL Server Santiago/Chile

    martes, 21 de agosto de 2018 23:09

Respuestas

  • Es bastante mala idea usar así el procedimiento con dos selects, porque devuelve dos esquemas distintos dependiendo del "If", y esto complica el uso de cualquier herramienta que deba analizar el espema en lado cliente. La cosa se complica mucho más si lo haces en un Insert o Update, porque los parámetros variarían dependiendo de la condición.

    Es preferible que hagas dos procedimientos, uno por cada tabla, y que el "if" lo tenga el código cliente y llame a un procedimiento o al otro.

    Por cierto, si los procedimientos no hacen nada más que contener una única sentencia para leer o grabar en una tabla, puedes ahorrarte los procedimientos y ejecutar la sentencia desde código cliente. Los motivos por los que antiguamente se decía que era preferible hacer esto desde un procedimiento almacenado en la actualidad están ya obsoletos, si se usa un lenguaje moderno y un servidor moderno y se parametrizan las sentencias correctamente (cosa que no lleva más trabajo porque en cualquier caso esa parametrización tendrías que hacerla de todas maneras en la llamada al procedimiento).

    • Marcado como respuesta CMAPM miércoles, 22 de agosto de 2018 11:56
    miércoles, 22 de agosto de 2018 6:05
  • Puedes filtrar dentro del where condicionando el parámetro:

    Select loQueSea from laTabla Where (@p1=0 AND campo1=valor1) OR  (@p1=1 AND campo2=valor2)

    Lo mismo vale también para el Where del Update.

    • Marcado como respuesta CMAPM jueves, 23 de agosto de 2018 19:05
    miércoles, 22 de agosto de 2018 17:06

Todas las respuestas

  • Es bastante mala idea usar así el procedimiento con dos selects, porque devuelve dos esquemas distintos dependiendo del "If", y esto complica el uso de cualquier herramienta que deba analizar el espema en lado cliente. La cosa se complica mucho más si lo haces en un Insert o Update, porque los parámetros variarían dependiendo de la condición.

    Es preferible que hagas dos procedimientos, uno por cada tabla, y que el "if" lo tenga el código cliente y llame a un procedimiento o al otro.

    Por cierto, si los procedimientos no hacen nada más que contener una única sentencia para leer o grabar en una tabla, puedes ahorrarte los procedimientos y ejecutar la sentencia desde código cliente. Los motivos por los que antiguamente se decía que era preferible hacer esto desde un procedimiento almacenado en la actualidad están ya obsoletos, si se usa un lenguaje moderno y un servidor moderno y se parametrizan las sentencias correctamente (cosa que no lleva más trabajo porque en cualquier caso esa parametrización tendrías que hacerla de todas maneras en la llamada al procedimiento).

    • Marcado como respuesta CMAPM miércoles, 22 de agosto de 2018 11:56
    miércoles, 22 de agosto de 2018 6:05
  • Alberto y si fuera la misma tabla con filtros diferentes ?

    2 ejemplso distintos Select  y UPDATE

    1 SP con Select misma tabla Where distinto

    1 SP con UPDATe misma tabla Where distinto

    Saludos.


    DBA SQL Server Santiago/Chile

    miércoles, 22 de agosto de 2018 16:55
  • Puedes filtrar dentro del where condicionando el parámetro:

    Select loQueSea from laTabla Where (@p1=0 AND campo1=valor1) OR  (@p1=1 AND campo2=valor2)

    Lo mismo vale también para el Where del Update.

    • Marcado como respuesta CMAPM jueves, 23 de agosto de 2018 19:05
    miércoles, 22 de agosto de 2018 17:06