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

Excelente Muchas Gracias Amigo, por tu tiempo y respuesta.
Saludos desde Nicaragua.
Don Quijote de Nicaragua.

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

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

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

Excelente Muchas Gracias Amigo, por tu tiempo y respuesta.
Saludos desde Nicaragua.
Don Quijote de Nicaragua.

A ver si otros te dan otras respuestas mas directas
a tu pregunta original. Como ya te habrás dado
cuenta, a mi ya solo la idea me bloquea la mente :)

Suerte con el asunto,
Carlos

No termino de ver lo práctico que pueda ser eso. Lo que estás queriendo
hacer presupone que todas las operaciones reciben el mismo número de
parámetros, es decir:

- En la inserción está claro que se necesitan todos los campos (o al menos
los que no tengan un valor predeterminado)
- En el borrado podrías necesitar únicamente la clave primaria, pero
podría ser que seleccionaras el registro en base a otros criterios
- En la actualización no veo por qué vas a tener que actualizar todos los
campos
- Las búsquedas es un ejemplo aún más claro, ya que habrá veces que
busques por un campo, por otro, por la combinación de ambos, etc.

Lo que quiero decir es que estáis mapeando una tabla con un procedimiento
almacenado directamente, lo cual creo que no es correcto. A mí me gusta
pensar los procedimientos almacenados como una capa de acceso que
proporcione los métodos adecuados para realizar operaciones contra la base
de datos. Por ejemplo, si tenemos la tabla "Usuarios" y "Emails", la
creación del usuario se haría por medio de un procedimiento almacenado que
controlara la inserción de los datos básicos del usuario, pero también los
correos electrónicos que pueda tener.

Es un ejemplo muy sencillo, pero lo que intento es expresar la idea. De
todos modos, este tema es uno de los más discutidos en la comunidad
(procedimientos almacenados sí o no), por lo que cada uno te dará una
opinión distinta.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Don Quijote de Nicaragua" wrote in message
news:
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

Muchas Gracias.
Don Quijote de Nicaragua.

Hola Carlos, me parece que lo de usar SQL Dinamico, no es conveniente por el
tema de performance, sino me equivoco haria que los palnes de ejecucion no
sean reutilizables.

En el caso de querer implementar todo en un SP podria usar como parametro_1,
el tipo de operacion, como parametro_2 un XML con los datos a
Updatear/Insertar, Parametro_3 Filtro (Updatear/Eliminar/Buscar)

Es solo una idea,

Saludos, dcaro

"Carlos M. Calvelo" escribió en el mensaje
news:
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

Hola Diego,

On Fri, 9 Oct 2009 15:30:00 -0300, DiegoC wrote:

Hola Carlos, me parece que lo de usar SQL Dinamico, no es conveniente por el
tema de performance, sino me equivoco haria que los palnes de ejecucion no
sean reutilizables.

Claro que no es conveniente. Lo conveniente es utizar las operaciones
select, insert, update y delete de SQL, que para eso están.

En el caso de querer implementar todo en un SP podria usar como parametro_1,
el tipo de operacion, como parametro_2 un XML con los datos a
Updatear/Insertar, Parametro_3 Filtro (Updatear/Eliminar/Buscar)

Y eso si sería 'conveniente'? Son entonces los planes de ejecución
reutilizables?

Yo no le veo ningún sentido a la idea orignal de no tener acceso a las
tablas si no es por medio de procedimientos. En cuanto no entienda
eso (desde la técnica, no la política de las empresas), cualquier
alternativa me va a parecer bastante 'chapuza'.

Saludos,
Carlos