Procedimientos Almacenados - Parametros

yo creo que en este debate hay dos areas: Por un lado: Los que trabajan
sólo con la base de datos y no manejan mucho el área de la programación y
las facilidades que brinda, que parece son mayoría en este foro. Y es logico
porque este no es un foro de programacion.

Y por otro lado: Los que trabajan tanto con la base de datos como con la
programación de la aplicación cliente y manejan lo las facilidades de ambos
mundos.


Para el tema especifico yo opino en parte lo que dice Melissa: construir en
un string una instruccion select y asignarsela a la propiedad "selectcmd" o
como se llame de un dataset para hacer luego hacer un fill del conjunto con
esa nueva instruccion no es permitir inyeccion de codigo en el servidor, y
si lo fuera no seria diferente del comportamiento por defecto que cuando se
asigna en tiempo de diseño esa instruccion select al dataset. Los lenguajes
no presuponen la existencia de un sp. Por que sin son tan necesarios ?

Y que cuando se usa ODBC ?, todo se pasa como una cadena de caracteres al
servidor inclusive un "EXEC NOMBREsp" ?, habria entonces posibilidad de
inyectar codigo a esta cadena y agregar otra cosa ?


LN



"Ricardo Passians" wrote in message
news:e6$

Porqué es que siempre todo para ustedes tiene que ser blanco o negro ? Yo
no he dicho que no uso SP's , los uso mucho hasta para los cruds, y para

la

mayoria de consultas "previstas". Aqui estamos hablando de una consulta
ad-hoc. Si leen bien mi mensaje ahí lo digo.

>
> El tema es que no estas haciendo un analisis completo del tema, por ej:

no

> mencionas que si no usas un Sp's vas a tener que darle acceso directo a
los
> usuarios a tus tablas,

bueno... acceso de consulta para tablas especificas. Cual es el problema

?

>no mencionas nada de mantenimiento por ej, a ver: que
> pasa si cambia algo en la BDD? debemos ir a buscar en toda aplicacion
donde
> este y volver a compilarlo, cuando si realmente usaras Sp's seria una
tarea
> muy simple.
>

Y tú programas tu aplicación, tus clases de manejo de datos (de capa de
datos) con código "duro" dependiente de la base de datos ? bueno... si es
así, tienes razón en lo que dices pero usas muy malas prácticas de
programación. En mi caso yo una consulta ad-hoc (que es una clase
parametrizable) la programo de forma genérica en la aplicación.

>
> Tampoco hablas de abstraccion, cuando trabajas en equipos de trabajos

los

> desarrolladores por lo general se encargan del codigo de la aplicacion y
> nada de la BDD, por lo cual para ellos los Sp's son la forma de conectar
un
> mundo con el otro sin importar que suceda atras :-)
>

Perfecto. Para darte solo un ejemplo ej. yo tengo para cada tabla un sp
XSP_I_NOMBRETABLA con los campos en parametros para insertar un registro.
Mis clases en la capa de datos de la aplicacion construyen (build) con el
nombre de la tabla y su estructura la cadena de llamada al SP y la lista

de

parametros a pasar a este SP. Los desarrolladores solo saben que hay una
rutina para cada tabla que espera un registro y un nombre de tabla. La
clase se encarga del resto. No hay ningún código "duro" aquí. Tambien
tengo SP's para consultas con nombres predeterminados coincidiendo con
nombres de forms para simplificar y generalizar el asunto, aqui tampoco

hay

nada de codigo duro. Lo que quiero decir que si tu programas tus clases

de

capa de datos en la aplicación a un nivel de abstracción (evitando la
cohesión), los problemas de mantenimiento son mínimos.

>
> Yo no soy un sp's maniaco, solo considero que son la herramienta que
> soluciona muchos de los problemas mas importantes de una aplicacion y

que

> sin ellos no los podrias resolver. Ahora, quizas para ti no sea
prioritario
> la seguridad - la performance, con lo cual mandar sentencias desde el
> cliente parece lo mas acertado,
>

Insisto, no es para todos los casos. No generalices. Relee mi mensaje.

>pues eso va en cada uno, es como todo, los
> software tambien tienen calidad como los autos, un BMW es un auto y un
FIAT
> tambien, pero sabemos que no son lo mismo.
>
> Ademas hacer las cosas bien no cuesta nada, es probable que por las
> aplicaciones que hagas no se vea la diferencia, pero al estar

acostumbrado

a
> las buenas practicas de programacion, cuando debas hacer un sistema para
un
> cliente mas exigente no tendras problemas.
>

Una aplicación no es sólo el servidor (el manejador de la base de datos).

La

aplicación cliente es también muy importante y parte esencial del "todo"
C/S.

Para concluir: A mi me luces que sólo te centras en el área del servidor

y

piensas que la programación en la parte cliente es tan rígida como lo es

(o

debe ser) en la parte servidor el T-SQL para que el servidor se maneje
eficientemente y con seguridad. En la aplicacion cliente uno tiene mayor
libertad de hacer cosas de modo genérico aunque se utilicen los SP's como
base fundamental del acceso a datos, son capas diferentes e

independientes.

Todo depende de cómo programes tu aplicación y del dominio que tengas del
lenguaje de programación y del conocimiento que tengas del desarrollo en
N-Capas.

>
> Un abrazo y Feliz 2005
>

Igual. Muchas felicidades.

>
>
>
> Maxi
>
> Buenos Aires - Argentina
> Desarrollador .NET 3 Estrellas
> Microsoft User Group (MUG)
>
> Msn Messenger:
>
> "Ricardo" escribió en el mensaje
> news:
> >
> > "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> > news:
> >> Ricardo,
> >>
> >> por que si armas un select en tu aplicación tienes los siguintes
> >> problemas.
> >>
> >> 1.- Sql Injection (alta probabilidad)
> >
> > No hablo de sql dinamico en el sp sino generar la instruccion select

en

la
> > aplicacion ANTES de postearlo al servidor. El riesgo no es mayor que
> > cuando
> > envies un simple select * from directamente sin tenerlo en SP. O tu

lo

> > haces absolutamente todo con SP ? incluso un simple 'select * from
tabla'
> > de
> > una tabla pequeña ? dependiendo del lenguaje que uses puede ser que

lo

> > estes haciendo sin darte cuenta siquiera. Ese es un tema discutible.
> >
> >> 2.- No es compilado por el sql, y por lo tanto no puede definir la
mejor
> >> ruta de ejecución, algo que para los reportes es vital.
> >
> > Todo depende de la frecuencia de uso. No todo tiene porque estar
> > pre-compilado, sencillamente porque no todo esta previsto en una
> > aplicacion.
> > El habla practicamente de una consulta AD-HOC que si entendi bien,

las

> > combinaciones que genere para meterla en un SP lo harian sumamente
> > complejo
> > de programar.
> >
> >>
> >> 3.- Complicas el desarrollo por que si cambias algo en tu base de

datos

> >> debes tocar el codigo.
> >>
> >
> > Puede ser pero si cambio algo en la base de datos tambien tendre que
> > "tocar"
> > el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> > aplicacion puede programarse de modo generico sin necesidad de código
> > "duro"
> > como lo es el SP fijo que recomiendas.
> >
> >>
> >> La forma correcta es hacer un SP y seguir lo que te mencionó Maxi de
los
> >> isnull.
> >>
> >
> > Los SP's son importantisimos estoy de acuerdo. Yo los uso para la
mayoría
> > de
> > las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
> > fundamento
> > en lo que dice pero hay que decir que es "SP maníaco". Hay algunos
casos
> > (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> > frecuencia del query y del caso particular que se trate (el cual no lo
sé
> > realmente). Ademas no estamos hablando aqui de modificaciones sino de
> > consultas.
> >
> >
> >> saludos.
> >>
> >> Patrick.
> >>
> >> "Ricardo Passians" escribió en el

mensaje

> >> news:
> >> > Y porque en vez de un procedimiento, mejor armas el select desde tu
> >> > aplicación ?
> >> > Hay casos (pocos si) donde no es practico tenerlo en un sp. Ahora
> >> > bien,
> >> si
> >> > insistes en ponerlo en un SP deberas manejar en el todas las
> > combinaciones
> >> > posibles y te convendrias hacer un script tambien desde tu sistema
que
> > te
> >> > genere el codigo del SP a un archivo, lo cortas y lo pegas en un
create
> >> proc
> >> > en el query analizer o enterprise manager.
> >> >
> >> > "Romero Diego" wrote in message
> >> > news:%
> >> > > Hola
> >> > > Todos
> >> > >
> >> > > Tengo un problema :
> >> > > La tabla que describo a continuación tiene muchos campos y tengo
que
> >> hacer
> >> > > un reporte donde en una lista esten los nombres de los campos y

el

> >> usuario
> >> > > seleccione los que desee filtrar, esto se hace desde VB
> >> > >
> >> > > El problema es como hago un procedimiento almacenado para paserle
los
> >> > > parametros segun los campos que seleccione o necesariamente debo
> >> > > crear
> >> > > parametro por campo ?
> >> > >
> >> > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea, IdColor,
> >> > IdTipoVeh,
> >> > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas, PesoVeh,
> >> > Pasajeros,
> >> > > PasajPie, CapTanque, NumeroMotor,
SerieChasis,
> >> > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla, IdMarLub,
> >> > IdEmpresa,
> >> > > IdPropietario,
> >> > > IdConductor, IdTipoPro,
> >> > Adquisicion,IdGrupo,VehPropio,
> >> > > IdProveedor, FecCompra, TarjetaProp, CostoCompra, ValorAvaludo,
> >> > > ValorAsegurado,ValorCupo, IdAdmon,
> >> > > NumContrato,ContratoActivo,FecIngreso,
> >> > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,
DocCompleta,
> >> > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
> >> > >
> >> ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
> >> > > CertMovilizacion, FecCertMovil, VigCertMovil, TarjetaOperacion,
> >> > FecTarjOper,
> >> > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
> >> > > Kilometraje, KmsCompra,
> >> > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> > ArchivoFoto,
> >> > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
> >> > > FROM Vehiculos
> >> > > WHERE ' aqui la condición que depende de los campos que
seleccione
> > el
> >> > > usuario
> >> > >
> >> > > gracias
> >> > >
> >> > >
> >> > >
> >> > > Diego
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Melisa, veo que estas confundida :-)

Vos los dataset los podes usar asi como bien decis o bien armar tu propio
CRUD, aqui podrias llamar a los Sp.

A ver, yo en mis dataset uso Sp's tengo el sp de insert, el del delete, el
de update y las consultas. Ahora si solo pegas el dataset como objeto y usas
el asistente, entonces no hay mas nada que decir.

Toda esta discusion va a ser eterna y te explico porque: La mayoria de los
programadores vienen de programar con repositorios no corporativos (Access,
Fox, Etc), ahora los repositorios corporativos estan al alcance de cualquier
programador, pero que pasa, hay que cambiar la forma de pensar y obviamente
de desarrollar, esto lleva tiempo.

Pero te comento, en la empresa donde estoy cuando vamos a comprar un sistema
que trabaje sobre nuestras bdd corporatovas, deben cumplir con algunas
reglas, y si por ej: se puede acceder a las tablas fuera de la aplicacion,
esta es rebotada y no se adquiere.

Otra cosa, es que tus comentarios estan mas apuntado a cuando sos
programador unico, cuando trabajas en entornos corporativos la cosa cambia
drasticamente.

Yo les aconsejo que si quieren usar repositorios corporativos hagas las
cosas como se deben (cuestan mas claro, pero es la forma correcta de hacerlo
en estos ambientes), de lo contrario no usen repositorios corporativos,
nadie los obliga :-)




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

Msn Messenger:

"Melissa Ruiz" escribió en el mensaje
news:

Oye una pregunta al ver estos temas:


Cuando uno en un sistema tiene un dataset y ordena al dataset que inserte
un
registro mandando a ejecutar el metodo digamos "INSERTRECORD", que es lo
que
hace realmente el dataset ? no es enviar una simple instruccion INSERT al
servidor ? Aqui no existe ningun SP que yo sepa , a no ser que una misma
lo haya creado.
Si fuera tan necesario un SP hasta para esto, los lenguajes de
programacion
que manejan bases de datos los exigirian. o no ?


La verdad que estoy confundida y mi opinión es que exageran un poco con
eso
de usar un SP para todo.


Melissa Ruiz





"MAXI" wrote in message
news:

Ricardo, creo que te estas basando en que un sp's es solo bueno por
performance, si miras ese lado solo, algunas de las cosas que decis son
ciertas :-)

El tema es que no estas haciendo un analisis completo del tema, por ej:
no
mencionas que si no usas un Sp's vas a tener que darle acceso directo a

los

usuarios a tus tablas, no mencionas nada de mantenimiento por ej, a ver:

que

pasa si cambia algo en la BDD? debemos ir a buscar en toda aplicacion

donde

este y volver a compilarlo, cuando si realmente usaras Sp's seria una

tarea

muy simple.

Tampoco hablas de abstraccion, cuando trabajas en equipos de trabajos los
desarrolladores por lo general se encargan del codigo de la aplicacion y
nada de la BDD, por lo cual para ellos los Sp's son la forma de conectar

un

mundo con el otro sin importar que suceda atras :-)

Yo no soy un sp's maniaco, solo considero que son la herramienta que
soluciona muchos de los problemas mas importantes de una aplicacion y que
sin ellos no los podrias resolver. Ahora, quizas para ti no sea

prioritario

la seguridad - la performance, con lo cual mandar sentencias desde el
cliente parece lo mas acertado, pues eso va en cada uno, es como todo,
los
software tambien tienen calidad como los autos, un BMW es un auto y un

FIAT

tambien, pero sabemos que no son lo mismo.

Ademas hacer las cosas bien no cuesta nada, es probable que por las
aplicaciones que hagas no se vea la diferencia, pero al estar
acostumbrado

a

las buenas practicas de programacion, cuando debas hacer un sistema para

un

cliente mas exigente no tendras problemas.

Un abrazo y Feliz 2005




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

Msn Messenger:

"Ricardo" escribió en el mensaje
news:
>
> "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> news:
>> Ricardo,
>>
>> por que si armas un select en tu aplicación tienes los siguintes
>> problemas.
>>
>> 1.- Sql Injection (alta probabilidad)
>
> No hablo de sql dinamico en el sp sino generar la instruccion select en

la

> aplicacion ANTES de postearlo al servidor. El riesgo no es mayor que
> cuando
> envies un simple select * from directamente sin tenerlo en SP. O tu lo
> haces absolutamente todo con SP ? incluso un simple 'select * from

tabla'

> de
> una tabla pequeña ? dependiendo del lenguaje que uses puede ser que
> lo
> estes haciendo sin darte cuenta siquiera. Ese es un tema discutible.
>
>> 2.- No es compilado por el sql, y por lo tanto no puede definir la

mejor

>> ruta de ejecución, algo que para los reportes es vital.
>
> Todo depende de la frecuencia de uso. No todo tiene porque estar
> pre-compilado, sencillamente porque no todo esta previsto en una
> aplicacion.
> El habla practicamente de una consulta AD-HOC que si entendi bien, las
> combinaciones que genere para meterla en un SP lo harian sumamente
> complejo
> de programar.
>
>>
>> 3.- Complicas el desarrollo por que si cambias algo en tu base de
>> datos
>> debes tocar el codigo.
>>
>
> Puede ser pero si cambio algo en la base de datos tambien tendre que
> "tocar"
> el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> aplicacion puede programarse de modo generico sin necesidad de código
> "duro"
> como lo es el SP fijo que recomiendas.
>
>>
>> La forma correcta es hacer un SP y seguir lo que te mencionó Maxi de

los

>> isnull.
>>
>
> Los SP's son importantisimos estoy de acuerdo. Yo los uso para la

mayoría

> de
> las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
> fundamento
> en lo que dice pero hay que decir que es "SP maníaco". Hay algunos

casos

> (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> frecuencia del query y del caso particular que se trate (el cual no lo

sé

> realmente). Ademas no estamos hablando aqui de modificaciones sino de
> consultas.
>
>
>> saludos.
>>
>> Patrick.
>>
>> "Ricardo Passians" escribió en el mensaje
>> news:
>> > Y porque en vez de un procedimiento, mejor armas el select desde tu
>> > aplicación ?
>> > Hay casos (pocos si) donde no es practico tenerlo en un sp. Ahora
>> > bien,
>> si
>> > insistes en ponerlo en un SP deberas manejar en el todas las
> combinaciones
>> > posibles y te convendrias hacer un script tambien desde tu sistema

que

> te
>> > genere el codigo del SP a un archivo, lo cortas y lo pegas en un

create

>> proc
>> > en el query analizer o enterprise manager.
>> >
>> > "Romero Diego" wrote in message
>> > news:%
>> > > Hola
>> > > Todos
>> > >
>> > > Tengo un problema :
>> > > La tabla que describo a continuación tiene muchos campos y tengo

que

>> hacer
>> > > un reporte donde en una lista esten los nombres de los campos y el
>> usuario
>> > > seleccione los que desee filtrar, esto se hace desde VB
>> > >
>> > > El problema es como hago un procedimiento almacenado para paserle

los

>> > > parametros segun los campos que seleccione o necesariamente debo
>> > > crear
>> > > parametro por campo ?
>> > >
>> > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea, IdColor,
>> > IdTipoVeh,
>> > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas, PesoVeh,
>> > Pasajeros,
>> > > PasajPie, CapTanque, NumeroMotor,

SerieChasis,

>> > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla, IdMarLub,
>> > IdEmpresa,
>> > > IdPropietario,
>> > > IdConductor, IdTipoPro,
>> > Adquisicion,IdGrupo,VehPropio,
>> > > IdProveedor, FecCompra, TarjetaProp, CostoCompra, ValorAvaludo,
>> > > ValorAsegurado,ValorCupo, IdAdmon,
>> > > NumContrato,ContratoActivo,FecIngreso,
>> > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,

DocCompleta,

>> > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
>> > >
>> ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
>> > > CertMovilizacion, FecCertMovil, VigCertMovil, TarjetaOperacion,
>> > FecTarjOper,
>> > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
>> > > Kilometraje, KmsCompra,
>> > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> ArchivoFoto,
>> > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
>> > > FROM Vehiculos
>> > > WHERE ' aqui la condición que depende de los campos que

seleccione

> el
>> > > usuario
>> > >
>> > > gracias
>> > >
>> > >
>> > >
>> > > Diego
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>

Ricardo, para hacerla corta:

El dia que trabajes en entornos corporativos realmente y para clientes con
cierta exigencia de calidad, te daras cuenta de todo lo que decimos aca.

Una consulta en el cliente es un acceso a las tablas de forma directa y esto
esta prohibido en muchas organizaciones donde tienen un depto de sistemas
serio.

Preguntale a un banco si va a permitir que desde un excel puedan levantar
datos a ver que te dicen? si quieres desarrollar aplicaciones no
corporativas usa Access y Fox que so muy bueno para eso, pero cuando saltas
a Oracle, sql o Db2 estas hablando de otro nivel de aplicaciones donde
entran en juego otras cuestiones.

Ahh y no es todo blanco o negro che, deberias leer un poco mas las
recomendaciones de la propia MS con respecto a este tema y te daras cuenta
de todo lo que estamos diciendo.

Si queres buscar estas recomendaciones las obtendras en PAG o en la parte de
arquitectura de MS

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

Msn Messenger:

"Ricardo Passians" escribió en el mensaje
news:e6$

Porqué es que siempre todo para ustedes tiene que ser blanco o negro ? Yo
no he dicho que no uso SP's , los uso mucho hasta para los cruds, y para
la
mayoria de consultas "previstas". Aqui estamos hablando de una consulta
ad-hoc. Si leen bien mi mensaje ahí lo digo.

El tema es que no estas haciendo un analisis completo del tema, por ej:
no
mencionas que si no usas un Sp's vas a tener que darle acceso directo a

los

usuarios a tus tablas,

bueno... acceso de consulta para tablas especificas. Cual es el problema
?

no mencionas nada de mantenimiento por ej, a ver: que
pasa si cambia algo en la BDD? debemos ir a buscar en toda aplicacion

donde

este y volver a compilarlo, cuando si realmente usaras Sp's seria una

tarea

muy simple.

Y tú programas tu aplicación, tus clases de manejo de datos (de capa de
datos) con código "duro" dependiente de la base de datos ? bueno... si es
así, tienes razón en lo que dices pero usas muy malas prácticas de
programación. En mi caso yo una consulta ad-hoc (que es una clase
parametrizable) la programo de forma genérica en la aplicación.

Tampoco hablas de abstraccion, cuando trabajas en equipos de trabajos los
desarrolladores por lo general se encargan del codigo de la aplicacion y
nada de la BDD, por lo cual para ellos los Sp's son la forma de conectar

un

mundo con el otro sin importar que suceda atras :-)

Perfecto. Para darte solo un ejemplo ej. yo tengo para cada tabla un sp
XSP_I_NOMBRETABLA con los campos en parametros para insertar un registro.
Mis clases en la capa de datos de la aplicacion construyen (build) con el
nombre de la tabla y su estructura la cadena de llamada al SP y la lista
de
parametros a pasar a este SP. Los desarrolladores solo saben que hay una
rutina para cada tabla que espera un registro y un nombre de tabla. La
clase se encarga del resto. No hay ningún código "duro" aquí. Tambien
tengo SP's para consultas con nombres predeterminados coincidiendo con
nombres de forms para simplificar y generalizar el asunto, aqui tampoco
hay
nada de codigo duro. Lo que quiero decir que si tu programas tus clases
de
capa de datos en la aplicación a un nivel de abstracción (evitando la
cohesión), los problemas de mantenimiento son mínimos.

Yo no soy un sp's maniaco, solo considero que son la herramienta que
soluciona muchos de los problemas mas importantes de una aplicacion y que
sin ellos no los podrias resolver. Ahora, quizas para ti no sea

prioritario

la seguridad - la performance, con lo cual mandar sentencias desde el
cliente parece lo mas acertado,

Insisto, no es para todos los casos. No generalices. Relee mi mensaje.

pues eso va en cada uno, es como todo, los
software tambien tienen calidad como los autos, un BMW es un auto y un

FIAT

tambien, pero sabemos que no son lo mismo.

Ademas hacer las cosas bien no cuesta nada, es probable que por las
aplicaciones que hagas no se vea la diferencia, pero al estar
acostumbrado

a

las buenas practicas de programacion, cuando debas hacer un sistema para

un

cliente mas exigente no tendras problemas.

Una aplicación no es sólo el servidor (el manejador de la base de datos).
La
aplicación cliente es también muy importante y parte esencial del "todo"
C/S.

Para concluir: A mi me luces que sólo te centras en el área del servidor
y
piensas que la programación en la parte cliente es tan rígida como lo es
(o
debe ser) en la parte servidor el T-SQL para que el servidor se maneje
eficientemente y con seguridad. En la aplicacion cliente uno tiene mayor
libertad de hacer cosas de modo genérico aunque se utilicen los SP's como
base fundamental del acceso a datos, son capas diferentes e
independientes.
Todo depende de cómo programes tu aplicación y del dominio que tengas del
lenguaje de programación y del conocimiento que tengas del desarrollo en
N-Capas.

Un abrazo y Feliz 2005

Igual. Muchas felicidades.

Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

Msn Messenger:

"Ricardo" escribió en el mensaje
news:
>
> "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> news:
>> Ricardo,
>>
>> por que si armas un select en tu aplicación tienes los siguintes
>> problemas.
>>
>> 1.- Sql Injection (alta probabilidad)
>
> No hablo de sql dinamico en el sp sino generar la instruccion select en

la

> aplicacion ANTES de postearlo al servidor. El riesgo no es mayor que
> cuando
> envies un simple select * from directamente sin tenerlo en SP. O tu lo
> haces absolutamente todo con SP ? incluso un simple 'select * from

tabla'

> de
> una tabla pequeña ? dependiendo del lenguaje que uses puede ser que
> lo
> estes haciendo sin darte cuenta siquiera. Ese es un tema discutible.
>
>> 2.- No es compilado por el sql, y por lo tanto no puede definir la

mejor

>> ruta de ejecución, algo que para los reportes es vital.
>
> Todo depende de la frecuencia de uso. No todo tiene porque estar
> pre-compilado, sencillamente porque no todo esta previsto en una
> aplicacion.
> El habla practicamente de una consulta AD-HOC que si entendi bien, las
> combinaciones que genere para meterla en un SP lo harian sumamente
> complejo
> de programar.
>
>>
>> 3.- Complicas el desarrollo por que si cambias algo en tu base de
>> datos
>> debes tocar el codigo.
>>
>
> Puede ser pero si cambio algo en la base de datos tambien tendre que
> "tocar"
> el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> aplicacion puede programarse de modo generico sin necesidad de código
> "duro"
> como lo es el SP fijo que recomiendas.
>
>>
>> La forma correcta es hacer un SP y seguir lo que te mencionó Maxi de

los

>> isnull.
>>
>
> Los SP's son importantisimos estoy de acuerdo. Yo los uso para la

mayoría

> de
> las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
> fundamento
> en lo que dice pero hay que decir que es "SP maníaco". Hay algunos

casos

> (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> frecuencia del query y del caso particular que se trate (el cual no lo

sé

> realmente). Ademas no estamos hablando aqui de modificaciones sino de
> consultas.
>
>
>> saludos.
>>
>> Patrick.
>>
>> "Ricardo Passians" escribió en el mensaje
>> news:
>> > Y porque en vez de un procedimiento, mejor armas el select desde tu
>> > aplicación ?
>> > Hay casos (pocos si) donde no es practico tenerlo en un sp. Ahora
>> > bien,
>> si
>> > insistes en ponerlo en un SP deberas manejar en el todas las
> combinaciones
>> > posibles y te convendrias hacer un script tambien desde tu sistema

que

> te
>> > genere el codigo del SP a un archivo, lo cortas y lo pegas en un

create

>> proc
>> > en el query analizer o enterprise manager.
>> >
>> > "Romero Diego" wrote in message
>> > news:%
>> > > Hola
>> > > Todos
>> > >
>> > > Tengo un problema :
>> > > La tabla que describo a continuación tiene muchos campos y tengo

que

>> hacer
>> > > un reporte donde en una lista esten los nombres de los campos y el
>> usuario
>> > > seleccione los que desee filtrar, esto se hace desde VB
>> > >
>> > > El problema es como hago un procedimiento almacenado para paserle

los

>> > > parametros segun los campos que seleccione o necesariamente debo
>> > > crear
>> > > parametro por campo ?
>> > >
>> > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea, IdColor,
>> > IdTipoVeh,
>> > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas, PesoVeh,
>> > Pasajeros,
>> > > PasajPie, CapTanque, NumeroMotor,

SerieChasis,

>> > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla, IdMarLub,
>> > IdEmpresa,
>> > > IdPropietario,
>> > > IdConductor, IdTipoPro,
>> > Adquisicion,IdGrupo,VehPropio,
>> > > IdProveedor, FecCompra, TarjetaProp, CostoCompra, ValorAvaludo,
>> > > ValorAsegurado,ValorCupo, IdAdmon,
>> > > NumContrato,ContratoActivo,FecIngreso,
>> > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,

DocCompleta,

>> > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
>> > >
>> ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
>> > > CertMovilizacion, FecCertMovil, VigCertMovil, TarjetaOperacion,
>> > FecTarjOper,
>> > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
>> > > Kilometraje, KmsCompra,
>> > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> ArchivoFoto,
>> > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
>> > > FROM Vehiculos
>> > > WHERE ' aqui la condición que depende de los campos que

seleccione

> el
>> > > usuario
>> > >
>> > > gracias
>> > >
>> > >
>> > >
>> > > Diego
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>>
>>
>
>

Luis, estas muy confundido hermano: yo soy desarrollador desde hace mas de
10años y trabajo en ambientes corporativos desde hace 5.

Creo que la diferencia es esta, quienes trabajan en ambientes corporativos y
quienes no.

La migracion aun no llego bien, porque antes con access y fox todo esto del
servidor no era relevante, pero ahora que sql llego a la gente estamos en un
problema serio, los desarrolladores piensan que sqlserver es una version
mejorara de Access y ahi esta el problema.

Pero dejemos el tema aca, primero lean las recomendaciones de MS en su
pagina de arquitectura y luego la seguimos, pero no tiene sentido discutir
algo que aun no entienden

Un abrazo




Maxi

Buenos Aires - Argentina
Desarrollador .NET 3 Estrellas
Microsoft User Group (MUG)

Msn Messenger:

"Luis Nivar" escribió en el mensaje
news:

yo creo que en este debate hay dos areas: Por un lado: Los que trabajan
sólo con la base de datos y no manejan mucho el área de la programación y
las facilidades que brinda, que parece son mayoría en este foro. Y es
logico
porque este no es un foro de programacion.

Y por otro lado: Los que trabajan tanto con la base de datos como con la
programación de la aplicación cliente y manejan lo las facilidades de
ambos
mundos.


Para el tema especifico yo opino en parte lo que dice Melissa: construir
en
un string una instruccion select y asignarsela a la propiedad "selectcmd"
o
como se llame de un dataset para hacer luego hacer un fill del conjunto
con
esa nueva instruccion no es permitir inyeccion de codigo en el servidor, y
si lo fuera no seria diferente del comportamiento por defecto que cuando
se
asigna en tiempo de diseño esa instruccion select al dataset. Los
lenguajes
no presuponen la existencia de un sp. Por que sin son tan necesarios ?

Y que cuando se usa ODBC ?, todo se pasa como una cadena de caracteres al
servidor inclusive un "EXEC NOMBREsp" ?, habria entonces posibilidad de
inyectar codigo a esta cadena y agregar otra cosa ?


LN



"Ricardo Passians" wrote in message
news:e6$

Porqué es que siempre todo para ustedes tiene que ser blanco o negro ?
Yo
no he dicho que no uso SP's , los uso mucho hasta para los cruds, y para

la

mayoria de consultas "previstas". Aqui estamos hablando de una consulta
ad-hoc. Si leen bien mi mensaje ahí lo digo.

>
> El tema es que no estas haciendo un analisis completo del tema, por ej:

no

> mencionas que si no usas un Sp's vas a tener que darle acceso directo a
los
> usuarios a tus tablas,

bueno... acceso de consulta para tablas especificas. Cual es el problema

?

>no mencionas nada de mantenimiento por ej, a ver: que
> pasa si cambia algo en la BDD? debemos ir a buscar en toda aplicacion
donde
> este y volver a compilarlo, cuando si realmente usaras Sp's seria una
tarea
> muy simple.
>

Y tú programas tu aplicación, tus clases de manejo de datos (de capa de
datos) con código "duro" dependiente de la base de datos ? bueno... si es
así, tienes razón en lo que dices pero usas muy malas prácticas de
programación. En mi caso yo una consulta ad-hoc (que es una clase
parametrizable) la programo de forma genérica en la aplicación.

>
> Tampoco hablas de abstraccion, cuando trabajas en equipos de trabajos

los

> desarrolladores por lo general se encargan del codigo de la aplicacion
> y
> nada de la BDD, por lo cual para ellos los Sp's son la forma de
> conectar
un
> mundo con el otro sin importar que suceda atras :-)
>

Perfecto. Para darte solo un ejemplo ej. yo tengo para cada tabla un sp
XSP_I_NOMBRETABLA con los campos en parametros para insertar un registro.
Mis clases en la capa de datos de la aplicacion construyen (build) con el
nombre de la tabla y su estructura la cadena de llamada al SP y la lista

de

parametros a pasar a este SP. Los desarrolladores solo saben que hay una
rutina para cada tabla que espera un registro y un nombre de tabla. La
clase se encarga del resto. No hay ningún código "duro" aquí.
Tambien
tengo SP's para consultas con nombres predeterminados coincidiendo con
nombres de forms para simplificar y generalizar el asunto, aqui tampoco

hay

nada de codigo duro. Lo que quiero decir que si tu programas tus clases

de

capa de datos en la aplicación a un nivel de abstracción (evitando la
cohesión), los problemas de mantenimiento son mínimos.

>
> Yo no soy un sp's maniaco, solo considero que son la herramienta que
> soluciona muchos de los problemas mas importantes de una aplicacion y

que

> sin ellos no los podrias resolver. Ahora, quizas para ti no sea
prioritario
> la seguridad - la performance, con lo cual mandar sentencias desde el
> cliente parece lo mas acertado,
>

Insisto, no es para todos los casos. No generalices. Relee mi mensaje.

>pues eso va en cada uno, es como todo, los
> software tambien tienen calidad como los autos, un BMW es un auto y un
FIAT
> tambien, pero sabemos que no son lo mismo.
>
> Ademas hacer las cosas bien no cuesta nada, es probable que por las
> aplicaciones que hagas no se vea la diferencia, pero al estar

acostumbrado

a
> las buenas practicas de programacion, cuando debas hacer un sistema
> para
un
> cliente mas exigente no tendras problemas.
>

Una aplicación no es sólo el servidor (el manejador de la base de datos).

La

aplicación cliente es también muy importante y parte esencial del "todo"
C/S.

Para concluir: A mi me luces que sólo te centras en el área del servidor

y

piensas que la programación en la parte cliente es tan rígida como lo es

(o

debe ser) en la parte servidor el T-SQL para que el servidor se maneje
eficientemente y con seguridad. En la aplicacion cliente uno tiene mayor
libertad de hacer cosas de modo genérico aunque se utilicen los SP's como
base fundamental del acceso a datos, son capas diferentes e

independientes.

Todo depende de cómo programes tu aplicación y del dominio que tengas del
lenguaje de programación y del conocimiento que tengas del desarrollo en
N-Capas.

>
> Un abrazo y Feliz 2005
>

Igual. Muchas felicidades.

>
>
>
> Maxi
>
> Buenos Aires - Argentina
> Desarrollador .NET 3 Estrellas
> Microsoft User Group (MUG)
>
> Msn Messenger:
>
> "Ricardo" escribió en el mensaje
> news:
> >
> > "Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
> > news:
> >> Ricardo,
> >>
> >> por que si armas un select en tu aplicación tienes los siguintes
> >> problemas.
> >>
> >> 1.- Sql Injection (alta probabilidad)
> >
> > No hablo de sql dinamico en el sp sino generar la instruccion select

en

la
> > aplicacion ANTES de postearlo al servidor. El riesgo no es mayor que
> > cuando
> > envies un simple select * from directamente sin tenerlo en SP. O tu

lo

> > haces absolutamente todo con SP ? incluso un simple 'select * from
tabla'
> > de
> > una tabla pequeña ? dependiendo del lenguaje que uses puede ser que

lo

> > estes haciendo sin darte cuenta siquiera. Ese es un tema discutible.
> >
> >> 2.- No es compilado por el sql, y por lo tanto no puede definir la
mejor
> >> ruta de ejecución, algo que para los reportes es vital.
> >
> > Todo depende de la frecuencia de uso. No todo tiene porque estar
> > pre-compilado, sencillamente porque no todo esta previsto en una
> > aplicacion.
> > El habla practicamente de una consulta AD-HOC que si entendi bien,

las

> > combinaciones que genere para meterla en un SP lo harian sumamente
> > complejo
> > de programar.
> >
> >>
> >> 3.- Complicas el desarrollo por que si cambias algo en tu base de

datos

> >> debes tocar el codigo.
> >>
> >
> > Puede ser pero si cambio algo en la base de datos tambien tendre que
> > "tocar"
> > el codigo del SP fijo que recomiendas. Casi es lo mismo. Mas aun la
> > aplicacion puede programarse de modo generico sin necesidad de código
> > "duro"
> > como lo es el SP fijo que recomiendas.
> >
> >>
> >> La forma correcta es hacer un SP y seguir lo que te mencionó Maxi de
los
> >> isnull.
> >>
> >
> > Los SP's son importantisimos estoy de acuerdo. Yo los uso para la
mayoría
> > de
> > las cosas. Pero "no todo en la vida son SP's". Maxi tiene mucho
> > fundamento
> > en lo que dice pero hay que decir que es "SP maníaco". Hay algunos
casos
> > (pocos insisto) donde no hay que ser tan rígido. Todo depende de la
> > frecuencia del query y del caso particular que se trate (el cual no
> > lo
sé
> > realmente). Ademas no estamos hablando aqui de modificaciones sino
> > de
> > consultas.
> >
> >
> >> saludos.
> >>
> >> Patrick.
> >>
> >> "Ricardo Passians" escribió en el

mensaje

> >> news:
> >> > Y porque en vez de un procedimiento, mejor armas el select desde
> >> > tu
> >> > aplicación ?
> >> > Hay casos (pocos si) donde no es practico tenerlo en un sp. Ahora
> >> > bien,
> >> si
> >> > insistes en ponerlo en un SP deberas manejar en el todas las
> > combinaciones
> >> > posibles y te convendrias hacer un script tambien desde tu sistema
que
> > te
> >> > genere el codigo del SP a un archivo, lo cortas y lo pegas en un
create
> >> proc
> >> > en el query analizer o enterprise manager.
> >> >
> >> > "Romero Diego" wrote in message
> >> > news:%
> >> > > Hola
> >> > > Todos
> >> > >
> >> > > Tengo un problema :
> >> > > La tabla que describo a continuación tiene muchos campos y tengo
que
> >> hacer
> >> > > un reporte donde en una lista esten los nombres de los campos y

el

> >> usuario
> >> > > seleccione los que desee filtrar, esto se hace desde VB
> >> > >
> >> > > El problema es como hago un procedimiento almacenado para
> >> > > paserle
los
> >> > > parametros segun los campos que seleccione o necesariamente debo
> >> > > crear
> >> > > parametro por campo ?
> >> > >
> >> > > SELECT IdVehiculo, Numero, IdClase, IdMarca, IdLinea,
> >> > > IdColor,
> >> > IdTipoVeh,
> >> > > IdTipoMot, AnnoModelo, FecRepotencia, Ejes, NumLlantas, PesoVeh,
> >> > Pasajeros,
> >> > > PasajPie, CapTanque, NumeroMotor,
SerieChasis,
> >> > > Cilindrada, IdTipoCom, IdTipoLla, IdTipoLub, IdMarLla, IdMarLub,
> >> > IdEmpresa,
> >> > > IdPropietario,
> >> > > IdConductor, IdTipoPro,
> >> > Adquisicion,IdGrupo,VehPropio,
> >> > > IdProveedor, FecCompra, TarjetaProp, CostoCompra, ValorAvaludo,
> >> > > ValorAsegurado,ValorCupo, IdAdmon,
> >> > > NumContrato,ContratoActivo,FecIngreso,
> >> > > FecRetiro,FecVigencia,FecSalida, VidaUtil, FecImpuestos,
DocCompleta,
> >> > > Accidentes,ObligaTProd, PolizaSoat,FecSoat,VigSoat,EmpresaSoat
> >> > >
> >> ,GarantiaAcc,PolizaResCivil,FecResCivil,VigResCivil,
> >> > > CertMovilizacion, FecCertMovil, VigCertMovil, TarjetaOperacion,
> >> > FecTarjOper,
> >> > > VigTarjOper, CertGases, FecCertGases, VigCertGases,
> >> > > Kilometraje, KmsCompra,
> >> > > Observacion,CentInicial,CentFinal,CupoCredito,SaldoActual,
> > ArchivoFoto,
> >> > > IdEstado, FechaAdd, FechaUpdate, IdUsuario
> >> > > FROM Vehiculos
> >> > > WHERE ' aqui la condición que depende de los campos que
seleccione
> > el
> >> > > usuario
> >> > >
> >> > > gracias
> >> > >
> >> > >
> >> > >
> >> > > Diego
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >>
> >>
> >
> >
>
>

Creo que la diferencia es esta, quienes trabajan en ambientes corporativos

y

quienes no.

O quizas en quienes trabajan para una sola empresa o corporacion y quienes
no.

Pero dejemos el tema aca, primero lean las recomendaciones de MS en su
pagina de arquitectura y luego la seguimos, pero no tiene sentido discutir
algo que aun no entienden

Pienso que si. Tienes algun enlace donde ver esas recomendaciones ?