Muchisimos SP's y funciones en una BD

Oye, yo no es que tenga tantos sp en una bd pero me imagino que eso en vez
de afectar el rendimiento lo que hara es mejorarlo pues los sp estaran
compilados en el servidor y se notara mas la mejoria cuando mas intensivo es
el uso. Asi que pienso que mientras mas sps se puedan tener es mucho mejor.
Claro solo es mi humilde opinion (mas una induccion) de novato en el tema.
Veamos otras opiniones de los compañeros del grupo.


Saludos

Raul



"Pedro Jose Caceres" wrote in message
news:

Saludos a todos

En una aplicacion lo estoy haciendo todo con SP's y funciones para por
seguridad evitar que los usuarios tengan acceso directo a las tablas. Eso
me ha hecho generar (dinamicamente por suerte:) a cada tabla de
mantenimiento del sistema un procedimiento para INSERT, otro para DELETE,
otro para UPDATE y ya que estoy en eso quise armar uno para navegacion

segun

sea: uno para ir al registro anterior, otro para ir al siguiente, otro

para

ir al ultimo y otro para ir al primero segun la clave primaria (la idea la
tome de leer varios posts de este foro). El asunto es que viendolo asi
tendria al menos 7 SP'S para cada tabla de mantenimiento del sistema lo

cual

quiere decir que si la aplicacion tiene 50 tablas de estas, tendria 350

SP's

de este tipo. Sin contar con todos los demas SP's y funciones de uso comun
para queries que uno suele hacer. Estimo que podrian haber mas de 500

entre

SP's y funciones.

Me preocupa si esta cantidad de procedimientos y funciones no me afectan

la

base de datos de alguna manera ya sea en rendimiento o de otra manera.

Podrian citar algunos casos de BD's con muchos SP's y funciones y como es

el

performance ?


Gracias

yo tambien soy principiante en todo esto, pero creo q' el problema no es
tanto cuantas tablas y/o SP's o UDF's tengas, sino que esten bien
normalizadas las primeras y que ni trabajes en balde programando a lo loco
ni que te falten procedimientos...

Por ejemplo, mencionas que estas usando SP's para ir al reg. anterior y
otros para el siguiente... ¿para que eso? ¿no puedes devolver de un solo
trancazo el conjunto de registros que un usuario vaya a necesitar para
algo y que la aplicacion cliente los tenga en memoria, localmente? El uso
de cursores ralentiza mucho el desempeño de sql server, es mejor que
mandes bloquezotes de datos a ir uno por uno...

o si estas haciendo algo como un SP. "PrimerRegistro" donde sencillamente
haces "SELECT TOP 1 * FROM MiTabla ORDER BY Indice" y otro "RegAnterior
(@Actual AS LONG)" = "SELECT TOP 1 * FROM MiTabla WHERE Indice =
(@Actual-1)"...

Planteate, ¿en verdad son necesarios todos estos SP's?

Por el desempeño no te preocupes, se que hay sistemas con cientos (o aun
miles) de tablas y centenas de SP's y el servidor como si nada... pero
cuestionate si es necesario todo eso, no trabajes en balde ;-)

Hola, bueno no es malo hacer lo que decis, es mas es una buena tecnica en
parte.

Te comento, yo tengo sistemas con mas de 1000 Sp's y nunca tuve problemas,
la ventaja que te dan los Sp's son muchas, pero las que mas destaco son

1) Seguridad
2) Manteniento
3) Performace
4) Reutilizacion
5) Abstraccion

La primera es porque no debes darle acceso directo a los usuarios de las
tablas, sino que lo haces via SP con lo cual no podra modificar ni extraer
datos de tu BDD a menos que lo haga por una aplicacion controlada.

El segundo punto se da por lo siguiente: Si no usas sp y escribis todo en
los clientes (que seria la otra opcion), el dia que cambies algo en la
estructura de la BDD vas a tener que ir a buscar a todos los clientes donde
hagas la llamada para poder modificarlo, en cambio si tenes Sp's es muy
simple saber los Sp's que llaman a esas tablas y modificarlos.

El punto 3 se da porque un SP compila el plan y lo mantiene, y si vos en
lugar de hacer esto envias consultas Sql por cada una de ellas hara una
compilacion (imaginate 1.000.000 de consultas iguales en un lapso de
segundos) seria una catastrofe

El punto 4 se da porque el Sp lo podrias reutilizar desde cualquier otro
lenguaje, ademas de tener el proceso de datos (capa de datos) centralizado.

Y el ultimo punto se da porque los programadores no deberan conocer las
estructuras de las BDD sino solamente los Sp's y sus parametros, luego lo
que pase para atras a ellos no les importa.

Bueno creo que di ya varias razones por las cuales son buenos los Sp's, el
otro tema es que dentro de estos Sp exista codifo bueno y que a nadie se le
ocurra armar un Sp para borrar archivos del dicos, compactar arcivos o esas
cosas. Ni tampoco Sp' donde tienen 500 lineas, todo tiene su medida y deben
recordar que T-Sql es un lenguaje para manejar basicamente datos, con lo
cual le falta por ahora toda la potencia que podria tener un c# o VB.net.

Ademas, tenes muchos Sp's no afecta en nada al servidor y si son ordenados y
ponen algun metodo para poder codificarlos, veran que es muy pero muy simple
su administracion.

Yo en lugar de preocuparme por cuentos Sp's voy a tener, me preocuparia por
hacer los mejores querys y que mi sistema sea super seguro, escalable y no
imposible de mantener.

Un abrazo




Maxi

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

Msn Messenger:

"Pedro Jose Caceres" escribió en el mensaje
news:

Saludos a todos

En una aplicacion lo estoy haciendo todo con SP's y funciones para por
seguridad evitar que los usuarios tengan acceso directo a las tablas. Eso
me ha hecho generar (dinamicamente por suerte:) a cada tabla de
mantenimiento del sistema un procedimiento para INSERT, otro para DELETE,
otro para UPDATE y ya que estoy en eso quise armar uno para navegacion
segun
sea: uno para ir al registro anterior, otro para ir al siguiente, otro
para
ir al ultimo y otro para ir al primero segun la clave primaria (la idea la
tome de leer varios posts de este foro). El asunto es que viendolo asi
tendria al menos 7 SP'S para cada tabla de mantenimiento del sistema lo
cual
quiere decir que si la aplicacion tiene 50 tablas de estas, tendria 350
SP's
de este tipo. Sin contar con todos los demas SP's y funciones de uso comun
para queries que uno suele hacer. Estimo que podrian haber mas de 500
entre
SP's y funciones.

Me preocupa si esta cantidad de procedimientos y funciones no me afectan
la
base de datos de alguna manera ya sea en rendimiento o de otra manera.

Podrian citar algunos casos de BD's con muchos SP's y funciones y como es
el
performance ?


Gracias

Gracias por la explicacion. Muy buena.

Una duda adicional: Todo eso aplica por igual a las funciones de usuario
(cuando sea practico utilizarlas ) ?




"MAXI" wrote in message
news:

Hola, bueno no es malo hacer lo que decis, es mas es una buena tecnica en
parte.

Te comento, yo tengo sistemas con mas de 1000 Sp's y nunca tuve problemas,
la ventaja que te dan los Sp's son muchas, pero las que mas destaco son

1) Seguridad
2) Manteniento
3) Performace
4) Reutilizacion
5) Abstraccion

La primera es porque no debes darle acceso directo a los usuarios de las
tablas, sino que lo haces via SP con lo cual no podra modificar ni extraer
datos de tu BDD a menos que lo haga por una aplicacion controlada.

El segundo punto se da por lo siguiente: Si no usas sp y escribis todo en
los clientes (que seria la otra opcion), el dia que cambies algo en la
estructura de la BDD vas a tener que ir a buscar a todos los clientes

donde

hagas la llamada para poder modificarlo, en cambio si tenes Sp's es muy
simple saber los Sp's que llaman a esas tablas y modificarlos.

El punto 3 se da porque un SP compila el plan y lo mantiene, y si vos en
lugar de hacer esto envias consultas Sql por cada una de ellas hara una
compilacion (imaginate 1.000.000 de consultas iguales en un lapso de
segundos) seria una catastrofe

El punto 4 se da porque el Sp lo podrias reutilizar desde cualquier otro
lenguaje, ademas de tener el proceso de datos (capa de datos)

centralizado.

Y el ultimo punto se da porque los programadores no deberan conocer las
estructuras de las BDD sino solamente los Sp's y sus parametros, luego lo
que pase para atras a ellos no les importa.

Bueno creo que di ya varias razones por las cuales son buenos los Sp's, el
otro tema es que dentro de estos Sp exista codifo bueno y que a nadie se

le

ocurra armar un Sp para borrar archivos del dicos, compactar arcivos o

esas

cosas. Ni tampoco Sp' donde tienen 500 lineas, todo tiene su medida y

deben

recordar que T-Sql es un lenguaje para manejar basicamente datos, con lo
cual le falta por ahora toda la potencia que podria tener un c# o VB.net.

Ademas, tenes muchos Sp's no afecta en nada al servidor y si son ordenados

y

ponen algun metodo para poder codificarlos, veran que es muy pero muy

simple

su administracion.

Yo en lugar de preocuparme por cuentos Sp's voy a tener, me preocuparia

por

hacer los mejores querys y que mi sistema sea super seguro, escalable y no
imposible de mantener.

Un abrazo




Maxi

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

Msn Messenger:

"Pedro Jose Caceres" escribió en el mensaje
news:
> Saludos a todos
>
> En una aplicacion lo estoy haciendo todo con SP's y funciones para por
> seguridad evitar que los usuarios tengan acceso directo a las tablas.

Eso

> me ha hecho generar (dinamicamente por suerte:) a cada tabla de
> mantenimiento del sistema un procedimiento para INSERT, otro para

DELETE,

> otro para UPDATE y ya que estoy en eso quise armar uno para navegacion
> segun
> sea: uno para ir al registro anterior, otro para ir al siguiente, otro
> para
> ir al ultimo y otro para ir al primero segun la clave primaria (la idea

la

> tome de leer varios posts de este foro). El asunto es que viendolo asi
> tendria al menos 7 SP'S para cada tabla de mantenimiento del sistema lo
> cual
> quiere decir que si la aplicacion tiene 50 tablas de estas, tendria 350
> SP's
> de este tipo. Sin contar con todos los demas SP's y funciones de uso

comun

> para queries que uno suele hacer. Estimo que podrian haber mas de 500
> entre
> SP's y funciones.
>
> Me preocupa si esta cantidad de procedimientos y funciones no me afectan
> la
> base de datos de alguna manera ya sea en rendimiento o de otra manera.
>
> Podrian citar algunos casos de BD's con muchos SP's y funciones y como

es

> el
> performance ?
>
>
> Gracias
>
>

Hola, las UDF son otra cosa muy distinta a los SP's por ej yo dispongo de
muy pocas UDF, solo las uso para casos muy especificos. Pero los Sp's son la
base de mis sistemas y te comento que cuando trabajas en entornos
corporativos hacer las cosas bien es muy importante.

Vos para que estas usando las UDF?




Maxi

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

Msn Messenger:

"Pedro Jose Caceres" escribió en el mensaje
news:

Gracias por la explicacion. Muy buena.

Una duda adicional: Todo eso aplica por igual a las funciones de usuario
(cuando sea practico utilizarlas ) ?




"MAXI" wrote in message
news:

Hola, bueno no es malo hacer lo que decis, es mas es una buena tecnica en
parte.

Te comento, yo tengo sistemas con mas de 1000 Sp's y nunca tuve
problemas,
la ventaja que te dan los Sp's son muchas, pero las que mas destaco son

1) Seguridad
2) Manteniento
3) Performace
4) Reutilizacion
5) Abstraccion

La primera es porque no debes darle acceso directo a los usuarios de las
tablas, sino que lo haces via SP con lo cual no podra modificar ni
extraer
datos de tu BDD a menos que lo haga por una aplicacion controlada.

El segundo punto se da por lo siguiente: Si no usas sp y escribis todo en
los clientes (que seria la otra opcion), el dia que cambies algo en la
estructura de la BDD vas a tener que ir a buscar a todos los clientes

donde

hagas la llamada para poder modificarlo, en cambio si tenes Sp's es muy
simple saber los Sp's que llaman a esas tablas y modificarlos.

El punto 3 se da porque un SP compila el plan y lo mantiene, y si vos en
lugar de hacer esto envias consultas Sql por cada una de ellas hara una
compilacion (imaginate 1.000.000 de consultas iguales en un lapso de
segundos) seria una catastrofe

El punto 4 se da porque el Sp lo podrias reutilizar desde cualquier otro
lenguaje, ademas de tener el proceso de datos (capa de datos)

centralizado.

Y el ultimo punto se da porque los programadores no deberan conocer las
estructuras de las BDD sino solamente los Sp's y sus parametros, luego lo
que pase para atras a ellos no les importa.

Bueno creo que di ya varias razones por las cuales son buenos los Sp's,
el
otro tema es que dentro de estos Sp exista codifo bueno y que a nadie se

le

ocurra armar un Sp para borrar archivos del dicos, compactar arcivos o

esas

cosas. Ni tampoco Sp' donde tienen 500 lineas, todo tiene su medida y

deben

recordar que T-Sql es un lenguaje para manejar basicamente datos, con lo
cual le falta por ahora toda la potencia que podria tener un c# o VB.net.

Ademas, tenes muchos Sp's no afecta en nada al servidor y si son
ordenados

y

ponen algun metodo para poder codificarlos, veran que es muy pero muy

simple

su administracion.

Yo en lugar de preocuparme por cuentos Sp's voy a tener, me preocuparia

por

hacer los mejores querys y que mi sistema sea super seguro, escalable y
no
imposible de mantener.

Un abrazo




Maxi

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

Msn Messenger:

"Pedro Jose Caceres" escribió en el mensaje
news:
> Saludos a todos
>
> En una aplicacion lo estoy haciendo todo con SP's y funciones para por
> seguridad evitar que los usuarios tengan acceso directo a las tablas.

Eso

> me ha hecho generar (dinamicamente por suerte:) a cada tabla de
> mantenimiento del sistema un procedimiento para INSERT, otro para

DELETE,

> otro para UPDATE y ya que estoy en eso quise armar uno para navegacion
> segun
> sea: uno para ir al registro anterior, otro para ir al siguiente, otro
> para
> ir al ultimo y otro para ir al primero segun la clave primaria (la idea

la

> tome de leer varios posts de este foro). El asunto es que viendolo asi
> tendria al menos 7 SP'S para cada tabla de mantenimiento del sistema lo
> cual
> quiere decir que si la aplicacion tiene 50 tablas de estas, tendria 350
> SP's
> de este tipo. Sin contar con todos los demas SP's y funciones de uso

comun

> para queries que uno suele hacer. Estimo que podrian haber mas de 500
> entre
> SP's y funciones.
>
> Me preocupa si esta cantidad de procedimientos y funciones no me
> afectan
> la
> base de datos de alguna manera ya sea en rendimiento o de otra manera.
>
> Podrian citar algunos casos de BD's con muchos SP's y funciones y como

es

> el
> performance ?
>
>
> Gracias
>
>