Store Procedure + Todo en un solo Procedimiento (Update, Delete, Inser,listar, buscar)

Hola Don QdN,

On 8 okt, 23:06, Don Quijote de Nicaragua wrote:

Hola a todos, me gustaría preguntar algo, estamos elaborando un
sistema y parece que tendremos que crear muchisiimo procedimientos
almacenados, entonces estamos tomando la desición de poner digamos si
es el procedimiento de Pais, dejar un único procedimiento denominado
"spPais" y poner dentro de él las opciones de nuevo, modificar,
borrar, listar, buscar, etc, y lo identificariamos por un parametro,
creen ustedes que estro tendria algún efecto en el rendimiento al
momento de ejecutarlo.

CREATE PROCEDURE spEjemplo
@valor1 integer = NULL ,
@valor2 VARCHAR(200) NULL,
@nType integer
AS BEGIN
IF @nType=1 INSERT INTO ..
ELSE IF =2
UPDATE CountryId=@CountryId;
ELSE IF @nType=0 DELET
END

Mi consejo es que paréis, volváis al cruze donde habéis tomado esa
decisión y hagáis una reevaluación.

Las operaciones select, insert, update y delete tal como las ofrece
SQL son para eso. Comparado con lo que pueden hacer esas
operaciones, los procedimientos que os estáis planteando son
irrisorios. Entonces la pregunta que haces sobre rendimiento
es (para mi) totalmente irrelevante.

Haceros estas preguntas:

Que van a hacer esos procedimientos que no se pueda hacer con
la combinación de las operaciones normales, constaints, triggers
y vistas? (Piensa también en operaciones 'set at a time'!)
Significa la existencia de esos procedimientos que vas a esconder
la estructura de la bbdd y no serán posibles las operaciones
normales? Si no es esí... que sentido tiene eso? Y si sí es así:
estáis haciendo un buen cambio en cuanto a interfaz con las
(también futuras) aplicaciones?

Saludos,
Carlos

Hola, muchas gracias por tomarte el tiempo para contestarme,
efectivmente la forma de hacerlo con procedimiento almacenados es por
que estamos desarrollando un software para una corporacion que
UNICAMENTE permite acceso a sus base de datos desde Store Procedure y
no otra forma, entonces habiamos decidido dejar todo en un solo
procedimiento como para actualizar, borrar y listar, etc, sin embargo
ahora tenemos la inquietud si tecnicamente eso seria correcto hacerlo
asi, mas que todo para no tener el monton de procedimientos y tambien
creemos que seria mas facil para el mantenimiento del sistema mismo,
tú consideras que no habria ningun problema en cuestion de rendimiento
por dejarlo todo en un solo Store Procedure?
Gracias.
Don Quijote de Nicaragua.

On 8 oct, 15:37, "Carlos M. Calvelo" wrote:

Hola Don QdN,

On 8 okt, 23:06, Don Quijote de Nicaragua wrote:



> Hola a todos, me gustaría preguntar algo, estamos elaborando un
> sistema y parece que tendremos que crear muchisiimo procedimientos
> almacenados, entonces estamos tomando la desición de poner digamos si
> es el procedimiento de Pais, dejar un único procedimiento denominado
> "spPais" y poner dentro de él las opciones de nuevo, modificar,
> borrar, listar, buscar, etc, y lo identificariamos por un parametro,
> creen ustedes que estro tendria algún efecto en el rendimiento al
> momento de ejecutarlo.

> CREATE PROCEDURE spEjemplo
> @valor1 integer = NULL ,
> @valor2 VARCHAR(200) NULL,
> @nType integer
> AS BEGIN
> IF @nType=1 INSERT INTO ..
> ELSE IF  =2
> UPDATE CountryId=@CountryId;
> ELSE IF @nType=0 DELET
> END

Mi consejo es que paréis, volváis al cruze donde habéis tomado esa
decisión y hagáis una reevaluación.

Las operaciones select, insert, update y delete tal como las ofrece
SQL son para eso. Comparado con lo que pueden hacer esas
operaciones, los procedimientos que os estáis planteando son
irrisorios.  Entonces la pregunta que haces sobre rendimiento
es (para mi) totalmente irrelevante.

Haceros estas preguntas:

Que van a hacer esos procedimientos que no se pueda hacer con
la combinación de las operaciones normales, constaints, triggers
y vistas? (Piensa también en operaciones 'set at a time'!)
Significa la existencia de esos procedimientos que vas a esconder
la estructura de la bbdd y no serán posibles las operaciones
normales? Si no es esí... que sentido tiene eso? Y si sí es así:
estáis haciendo un buen cambio en cuanto a interfaz con las
(también futuras) aplicaciones?

Saludos,
Carlos

Hola,

On 8 okt, 23:50, Don Quijote de Nicaragua wrote:

Hola, muchas gracias por tomarte el tiempo para contestarme,
efectivmente la forma de hacerlo con procedimiento almacenados es por
que estamos desarrollando un software para una corporacion que
UNICAMENTE permite acceso a sus base de datos desde Store Procedure y
no otra forma,

Ah! :-)
Entonces es decisión y 'problema' de tal corporación.

entonces habiamos decidido dejar todo en un solo
procedimiento como para actualizar, borrar y listar, etc, sin embargo
ahora tenemos la inquietud si tecnicamente eso seria correcto hacerlo
asi, mas que todo para no tener el monton de procedimientos y tambien
creemos que seria mas facil para el mantenimiento del sistema mismo,
tú consideras que no habria ningun problema en cuestion de rendimiento
por dejarlo todo en un solo Store Procedure?

No creo que se note diferencia en rendimiento si tienes tres o
cuatro procediminetos o uno con un par de IF's.
Dada la situación yo escogería aquella forma con la que los que
teneis que trabajar con esos procediminetos os sintáis mas
confortables.

Naturalmene 'buscar' y 'listar' tiene otra interfaz (devuelven
tablas) que los insert, delete y update.

En cuanto a esa regla tajante de la organizacion... (y por ser
un poco terco)... y que pasa si solo montáis un par de procedimientos
que reciben una cadena con instruciones SQL y este se ejecuta como
sql dinámico en el procedimiento? :-) :-)

Saludos,
Carlos

jajaja interesante respuesta esta:

En cuanto a esa regla tajante de la organizacion... (y por ser
un poco terco)... y que pasa si solo montáis un par de procedimientos
que reciben una cadena con instruciones SQL y este se ejecuta como
sql dinámico en el procedimiento?

Tienes un ejemplo o una dirección donde pueda leer de como podría ser
esto último que dices, me gusta mucho la idea.

On 8 oct, 16:08, "Carlos M. Calvelo" wrote:

Hola,

On 8 okt, 23:50, Don Quijote de Nicaragua wrote:

> Hola, muchas gracias por tomarte el tiempo para contestarme,
> efectivmente la forma de hacerlo con procedimiento almacenados es por
> que estamos desarrollando un software para una corporacion que
> UNICAMENTE permite acceso a sus base de datos desde Store Procedure y
> no otra forma,

Ah!  :-)
Entonces es decisión y 'problema' de tal corporación.

> entonces habiamos decidido dejar todo en un solo
> procedimiento como para actualizar, borrar y listar, etc, sin embargo
> ahora tenemos la inquietud si tecnicamente eso seria correcto hacerlo
> asi, mas que todo para no tener el monton de procedimientos y tambien
> creemos que seria mas facil para el mantenimiento del sistema mismo,
> tú consideras que no habria ningun problema en cuestion de rendimiento
> por dejarlo todo en un solo Store Procedure?

No creo que se note diferencia en rendimiento si tienes tres o
cuatro procediminetos o uno con un par de IF's.
Dada la situación yo escogería aquella forma con la que los que
teneis que trabajar con esos procediminetos os sintáis mas
confortables.

Naturalmene 'buscar' y 'listar' tiene otra interfaz (devuelven
tablas) que los insert, delete y update.

En cuanto a esa regla tajante de la organizacion... (y por ser
un poco terco)... y que pasa si solo montáis un par de procedimientos
que reciben una cadena con instruciones SQL y este se ejecuta como
sql dinámico en el procedimiento?  :-) :-)

Saludos,
Carlos

On 9 okt, 00:15, Don Quijote de Nicaragua wrote:

jajaja interesante respuesta esta:

>En cuanto a esa regla tajante de la organizacion... (y por ser
>un poco terco)... y que pasa si solo montáis un par de procedimientos
>que reciben una cadena con instruciones SQL y este se ejecuta como
>sql dinámico en el procedimiento?

Tienes un ejemplo o una dirección donde pueda leer de como podría ser
esto último que dices, me gusta mucho la idea.

Hombre.. yo me lo he inventado así 'al vuelo'. Y es medio en broma :)

create table T
(
col1 varchar(50) ,
col2 varchar(50),
col3 int
)
go

create procedure ProcPorExcelencia(@sql_sentence nvarchar(max))
as
begin
exec sp_executesql @sql_sentence
end
go

execute dbo.procporexcelencia
'insert T (col1,col2, col3) values (''Hola'',''Adios'', 4)'

execute dbo.procporexcelencia 'select * from T'

drop table T
drop proc ProcPorExcelencia
-

No creo que sea esto lo que quiere decir tal organizción cuando dice
que "UNICAMENTE permite acceso a sus base de datos desde Store
Procedure" :-)

Saludos,
Carlos