none
Creando Procedimiento almacenados filtrar datos varias tablas, manera correcta RRS feed

  • Pregunta

  • Estoy creando procedimientos almacenados , pero tengo la necesidad de realizar buscar en la base de datos, asi:

    CREATE PROC BuscarID
     @ID as int
     as
     begin
      select * from [Infraccion Penal]
      where Id_InfraccionPenal=@ID
      select * from Programa
      where Id_Programa=@ID
     end

    lo que deseo saber si es la manera correcta de crear un procedure o no.

    porque he creado tantos procedimientos (tengo 12 tablas y a cada una les he creado procedimientos de inserta, modificar, eliminar, mostrar y buscar); las cuales han salido muchos. Esa es la manera o hay formas para simplificar...gracias de antemano por su ayuda y sugerencias.

    martes, 9 de mayo de 2017 20:57

Respuestas

  • Desde mi forma de ver las cosas no me gusta y creo que no es lo correcto. 

    Fíjate que "a fuerza" el procedimiento almacenado podría retornar filas en los dos conjuntos de resultados (en caso el valor del parámetro coincida con el valor de las columnas que participan en la expresión de filtro), si bien puedes decidir que conjunto tomar penalizas rendimiento en intentar recuperar datos que no necesitas, claro, el procedimiento podría filtrar por un tipo que determine la consulta de selección a realizar pero es "ensuciar" el código, no me gusta, entorpeces la legibilidad, el mantenimiento y produces un plan de ejecución "torpe".

    Si decides escribir procedimientos almacenados procura que cada uno de ellos realice una tarea en particular, evita la practica de "multi-próposito". Si deseas ahorrar tiempo de desarrollo en escribir objetos de acceso a datos puedes considerar la posibilidad de utilizar algún ORM como Entity Framework.



    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    martes, 9 de mayo de 2017 22:03

Todas las respuestas

  • Desde mi forma de ver las cosas no me gusta y creo que no es lo correcto. 

    Fíjate que "a fuerza" el procedimiento almacenado podría retornar filas en los dos conjuntos de resultados (en caso el valor del parámetro coincida con el valor de las columnas que participan en la expresión de filtro), si bien puedes decidir que conjunto tomar penalizas rendimiento en intentar recuperar datos que no necesitas, claro, el procedimiento podría filtrar por un tipo que determine la consulta de selección a realizar pero es "ensuciar" el código, no me gusta, entorpeces la legibilidad, el mantenimiento y produces un plan de ejecución "torpe".

    Si decides escribir procedimientos almacenados procura que cada uno de ellos realice una tarea en particular, evita la practica de "multi-próposito". Si deseas ahorrar tiempo de desarrollo en escribir objetos de acceso a datos puedes considerar la posibilidad de utilizar algún ORM como Entity Framework.



    Espero que la información proporcionada te haya sido de utilidad, quedo atento a tus comentarios.
    martes, 9 de mayo de 2017 22:03
  • Saludos,

    Concuerdo con lo que dice nuestro compañero, cada Stored que crees debe ser especializado en algo: insertar, actualizar, buscar, etc. En el caso que presentas evita usar el comodin (*), en general escribe el nombre de cada campo y trata de invocar como mínimo Esquema.Tabla.

    Podrías mejorar tu stored así:

    CREATE PROC Buscar_InfraccionPenalID
    ( 
    	@ID as int
    )
    AS
    SET NOCOUNT ON
    BEGIN
    
    SELECT
    	Campo1,
    	Campo2,
    	Campo3
    WHERE
    	dbo.Id_InfraccionPenal = @ID
    
    END
    GO
    Además cuida la identación al escribir el stored, de esta forma es más fácil de leerlo y darle mantenimiento a futuro


    Ayacucho - Perú
    Recuerda si mi solución atiende tu consulta por favor márcala como útil y como respuesta.

    http://litigiouslobo.blogspot.com/
    El Blog de Steve Morrison

    • Editado Nathán XS miércoles, 10 de mayo de 2017 16:14
    miércoles, 10 de mayo de 2017 16:09
  • No es la forma optima, de hecho podría ni funcionar, en tu caso @id es un int para ambas tablas pero algunas de ellas podría no serlo.  Lo mejor es crear procedimientos específicos. De todas formas siempre depende de cuales sean los requisitos de tu aplicación.

    Comparte lo que sepas, aprende lo que no sepas (FGG)
    portalSQL
    El rincón del DBA

    miércoles, 10 de mayo de 2017 17:20
    Moderador