Procedimientos Almacenados - Parametros

"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,

el sql injection se produce por el armado de sql dinamicamente, ya sea
en el sp o en tu programa. Y respondiento a tu pregunta, si, hago todo con
SPs, que no son dinámicos. Todo armado y precompilado. Todos los excecution
plans revisados y depurados al máximo. Todas las consultas optimizadas y los
indices creados en las tablas, ya sean clustered o no. Además, con sps
minimizas el manejo de permisos en la base de datos, o tu le das todos los
permisos a todas las tablas para el usuario con que te logeas? o lo dejas
como dueño de la base de datos?

Es exactamente esa complejidad que estas programando en la consulta la que
hará que el sqlserver pueda obtener los mejores caminos de ejecución. Si el
sql cambia a cada rato, los caminos no serán los optimos.

Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
funcionalidad de tu programa. Son ajustes menores. Es la base de cualquier
desarrolo en capas.

No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de datos.

Patrick.

"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
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>

Hola, opino tal cual como vos, el tema es que los SP's nos dan seguridad en
la aplicacion - mejor mantenimiento y mejor performance. Yo en mis
aplicaciones jamas uso sql desde la aplicacion, esto trae muchos problemas
como bien has indicado vos. Lo ideal seria trabajar con SP de tal manera que
nos aisle de todo.

Un abrazo




Maxi

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

Msn Messenger:

"Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
news:%

Ricardo,

el sql injection se produce por el armado de sql dinamicamente, ya sea
en el sp o en tu programa. Y respondiento a tu pregunta, si, hago todo
con
SPs, que no son dinámicos. Todo armado y precompilado. Todos los
excecution
plans revisados y depurados al máximo. Todas las consultas optimizadas y
los
indices creados en las tablas, ya sean clustered o no. Además, con sps
minimizas el manejo de permisos en la base de datos, o tu le das todos los
permisos a todas las tablas para el usuario con que te logeas? o lo dejas
como dueño de la base de datos?

Es exactamente esa complejidad que estas programando en la consulta la que
hará que el sqlserver pueda obtener los mejores caminos de ejecución. Si
el
sql cambia a cada rato, los caminos no serán los optimos.

Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
funcionalidad de tu programa. Son ajustes menores. Es la base de cualquier
desarrolo en capas.

No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de
datos.

Patrick.

"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
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>

Bien. Esa es la forma.

Patrick.

"MAXI" escribió en el mensaje
news:#

Hola, opino tal cual como vos, el tema es que los SP's nos dan seguridad

en

la aplicacion - mejor mantenimiento y mejor performance. Yo en mis
aplicaciones jamas uso sql desde la aplicacion, esto trae muchos problemas
como bien has indicado vos. Lo ideal seria trabajar con SP de tal manera

que

nos aisle de todo.

Un abrazo




Maxi

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

Msn Messenger:

"Patrick Mac Kay" <pmackay_at_hotmail.com> escribió en el mensaje
news:%
> Ricardo,
>
> el sql injection se produce por el armado de sql dinamicamente, ya

sea

> en el sp o en tu programa. Y respondiento a tu pregunta, si, hago todo
> con
> SPs, que no son dinámicos. Todo armado y precompilado. Todos los
> excecution
> plans revisados y depurados al máximo. Todas las consultas optimizadas y
> los
> indices creados en las tablas, ya sean clustered o no. Además, con sps
> minimizas el manejo de permisos en la base de datos, o tu le das todos

los

> permisos a todas las tablas para el usuario con que te logeas? o lo

dejas

> como dueño de la base de datos?
>
> Es exactamente esa complejidad que estas programando en la consulta la

que

> hará que el sqlserver pueda obtener los mejores caminos de ejecución. Si
> el
> sql cambia a cada rato, los caminos no serán los optimos.
>
> Si cambias los datos, cambias el sp, eso es obvio, pero no tocas la
> funcionalidad de tu programa. Son ajustes menores. Es la base de

cualquier

> desarrolo en capas.
>
> No es ser sp maniaco. Es obtener el mejor resultado de tu servidor de
> datos.
>
> Patrick.
>
> "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, 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
> >
> >
> >
> >
> >
>
>