Prodimientos almacenados (llevar todo ahi?)

Hola Pablo,

La verdad que sobre este tema he oído opiniones muy muy diversas. Los
desarrolladores te darán razones para incluirlas fuera del servidor, y
posiblemente en este grupo tengamos más tendencia a incluirlas en el
servidor :-). Por eso te recomiendo que realices también la pregunta en
grupos de desarrollo y obtendrás un visión más amplia.
A ver qué opinan el resto de compañeros.

Mi recomendación, un poco genérica eso si, es que toda la parte que tenga
que hacer uso intensido de acceso a datos se incluya en el servidor
(utilizando procedimientos almacenados, triggers, UDFs, ...), e incluso
parte de las reglas de negocio, sobre todo aquellas que se adapten más
fácilmente al lenguaje T-SQL. Y luego dejaría fuera del servidor las reglas
de negocio más complejas que requieran más código complejo de implementar en
T-SQL. Siempre hay que tener en cuenta la cantidad de datos que deberá
devolver el servidor para que puedan ejecutarse dichas reglas de negocio,
por ejemplo si tenemos un proceso que envía mucha información al cliente, la
procesa y luego tiene que devolverla al servidor, eso mejor hacerlo en el
servidor, bien con T-SQL, bien si esto es complejo apoyándonos en el CLR. En
cambio otro tipo de procesos que no van a generar mucho tráfico de red por
el envío de datos entre el cliente y el servidor, pero que requieren cierta
complejidad, estos los llevaría al cliente.

Otra recomendación, lo que si me plantearía es utilizar algún generador de
código o crearte el tuyo propio, para tareas repetitivas, ya que siempre
habrá muchas tablas sin (o casi) sin lógica de negocio, las típicas tablas
auxiliares. Por ejemplo para crear procedimientos insert, update, delete por
cada tabla ...

Te paso también este link por si te puede aportar algo:
http://www.geocities.com/SiliconVal...egocio.htm

Un saludo
Salvador Ramos

www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm


"Pablo Roca" escribió en el mensaje
news:

Hola,

Bueno estuve viendo como funcionan los procedimientos y la verdad que
resultan muy interesantes.

En una aplicacion de gestion tipica ...

Hasta uno donde debe utilizar procedimientos almacenados? Es decir ..
¿llevamos la mayor parte de nuestro codigo para ahi? solo las partes mas
criticas de una aplicación? .. Solo las consultas mas complejas ... todo?

¿Donde está el limite?


PD: Me importa muy poco que me vean mi codigo de los procedimientos
almacenados, es para aplicaciones internas.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Gracias por la respuesta Salvador.

Los desarrolladores darán razones para incluirlas fuera del servidor? mm,
estoy por pensar que esos desarrolladores saben de su herramienta de
desarrollo y poco sobre la base de datos, entonces se llevan esa parte al
terreno que dominan :))

Vamos, que veo interesantisimo utilizar procedimientos almacenados. Siempre
puede hacer uno que su capa de negocio llame a los procedimientos
almacenados y si partes interesa hacerlas en la capa de negocio, pues ahi se
hacen.

El tema es ese .. por ejemplo .. con mi aplicación que maneja 200 y pico
tablas .. ¿me pongo a hacer procedimientos almacenados como dogma? esto me
haria tener ya de entrada un minimo de 800 (200 x 4, es decir todo el CRUD)
procedimientos almacenados en una sola base de datos. Esto sería por cada
empresa-ejercicio, considerando unas 7 empresas y 5 ejercicios.

¿Es esto razonable? o se me está yendo la pinza? :-)

Si, como generador de codigo para procedimientos almacenados ya vi por
ejemplo este:

Lattice.SPGen
http://www.latticesoft.com/Products...tabindex=1

Que por lo que cuesta (88 euros), me sale mas a cuenta que hacer mi propio
generador.

Si sabeis de algun otro generador interesante, lo agradeceré.

Gracias por el link.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Bueno, esto da pie a otra típica discusión :-)

Por qué una base de datos por empresa y ejercicio ??? Yo haría una sola base
de datos o una por empresa (habría que estudiar tu caso concreto), y donde
sea necesario incluiría las columnas empresa y/o ejercicio.
Te recomiendo la lectura de estos hilos, donde se ha tratado este tema
ampliamente:

http://groups.google.es/group/micro...351b02ef08

http://groups.google.es/group/micro...f443975acc

http://groups.google.es/group/micro...24ba12f705

http://groups.google.es/group/micro...ab714857a3

Es más te invito a que abras otro hilo sobre este tema para no mezclar las
repuestas, si tras leer estos hilos tienes inquietudes y opiniones sobre el
tema.

Al número de procedimientos almacenados no le veo ningún problema, salvo si
optas por tantas bases de datos, el mantenerlos actualizados. Estudia
primero lo anterior y en función de la solución ya vemos soluciones para
esto.

En cuanto al generador, bueno, el tema es que cada uno tenemos nuestros
gustos en la escritura de código, y yo miraría a ver si ese generador se
adapta a lo que necesitas.

Un saludo
Salvador Ramos

www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm


"Pablo Roca" escribió en el mensaje
news:

Gracias por la respuesta Salvador.

Los desarrolladores darán razones para incluirlas fuera del servidor? mm,
estoy por pensar que esos desarrolladores saben de su herramienta de
desarrollo y poco sobre la base de datos, entonces se llevan esa parte al
terreno que dominan :))

Vamos, que veo interesantisimo utilizar procedimientos almacenados.
Siempre puede hacer uno que su capa de negocio llame a los procedimientos
almacenados y si partes interesa hacerlas en la capa de negocio, pues ahi
se hacen.

El tema es ese .. por ejemplo .. con mi aplicación que maneja 200 y pico
tablas .. ¿me pongo a hacer procedimientos almacenados como dogma? esto me
haria tener ya de entrada un minimo de 800 (200 x 4, es decir todo el
CRUD) procedimientos almacenados en una sola base de datos. Esto sería por
cada empresa-ejercicio, considerando unas 7 empresas y 5 ejercicios.

¿Es esto razonable? o se me está yendo la pinza? :-)

Si, como generador de codigo para procedimientos almacenados ya vi por
ejemplo este:

Lattice.SPGen
http://www.latticesoft.com/Products...tabindex=1

Que por lo que cuesta (88 euros), me sale mas a cuenta que hacer mi propio
generador.

Si sabeis de algun otro generador interesante, lo agradeceré.

Gracias por el link.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Compañeros, un saludos

Yo te recomiendo que tengas mucho cuidado con hacer una base de datos por
cada empresa y por cada ejercicio, te comento.

Actualmente estoy haciendo mantenimiento a una aplicación que debe mantener
datos de otra y en ocasiones también traer datos de aquella, ahora, que
sucede.

La aplicación de mi cliente fue hecha con una sola base de datos para todos
los ejercicios, pero, la base de datos de la otra aplicación utiliza una por
cada departamento, a la hora de realizar las consultas e incluso algunos
mantenimientos hay que poner en el código el nombre de la base de datos,
pero... no se puede saber de antemano el nombre de dichas base de datos.

claro que se puede solucionar con algo como:

exec ( "select * " + @dbName + '..dbo.tabla where .'

Pero, todos sabemos los inconvenientes al respeto.

Yo, siempre utilizo todo en una misma base de datos, en fin MsSQL está hecho
para manejar grandes volumenes de datos.

Creo que en alguna parte de éste grupo vi una discución sobre el tema, muy
interesante por cierto, lamentablemente no estoy seguro si fue aqui, si
alguien lo sabe, por favor postear el enlace para el compañero.

Saludos.


"Salvador Ramos" escribió en el
mensaje news:%23zoXV%

Bueno, esto da pie a otra típica discusión :-)

Por qué una base de datos por empresa y ejercicio ??? Yo haría una sola
base de datos o una por empresa (habría que estudiar tu caso concreto), y
donde sea necesario incluiría las columnas empresa y/o ejercicio.
Te recomiendo la lectura de estos hilos, donde se ha tratado este tema
ampliamente:

http://groups.google.es/group/micro...351b02ef08

http://groups.google.es/group/micro...f443975acc

http://groups.google.es/group/micro...24ba12f705

http://groups.google.es/group/micro...ab714857a3

Es más te invito a que abras otro hilo sobre este tema para no mezclar las
repuestas, si tras leer estos hilos tienes inquietudes y opiniones sobre
el tema.

Al número de procedimientos almacenados no le veo ningún problema, salvo
si optas por tantas bases de datos, el mantenerlos actualizados. Estudia
primero lo anterior y en función de la solución ya vemos soluciones para
esto.

En cuanto al generador, bueno, el tema es que cada uno tenemos nuestros
gustos en la escritura de código, y yo miraría a ver si ese generador se
adapta a lo que necesitas.

Un saludo
Salvador Ramos

www.helpdna.net (información sobre SQL Server y Microsoft .Net)
www.helpdna.net/acerca_de_salvador_ramos.htm


"Pablo Roca" escribió en el mensaje
news:

Gracias por la respuesta Salvador.

Los desarrolladores darán razones para incluirlas fuera del servidor? mm,
estoy por pensar que esos desarrolladores saben de su herramienta de
desarrollo y poco sobre la base de datos, entonces se llevan esa parte al
terreno que dominan :))

Vamos, que veo interesantisimo utilizar procedimientos almacenados.
Siempre puede hacer uno que su capa de negocio llame a los procedimientos
almacenados y si partes interesa hacerlas en la capa de negocio, pues ahi
se hacen.

El tema es ese .. por ejemplo .. con mi aplicación que maneja 200 y pico
tablas .. ¿me pongo a hacer procedimientos almacenados como dogma? esto
me haria tener ya de entrada un minimo de 800 (200 x 4, es decir todo el
CRUD) procedimientos almacenados en una sola base de datos. Esto sería
por cada empresa-ejercicio, considerando unas 7 empresas y 5 ejercicios.

¿Es esto razonable? o se me está yendo la pinza? :-)

Si, como generador de codigo para procedimientos almacenados ya vi por
ejemplo este:

Lattice.SPGen
http://www.latticesoft.com/Products...tabindex=1

Que por lo que cuesta (88 euros), me sale mas a cuenta que hacer mi
propio generador.

Si sabeis de algun otro generador interesante, lo agradeceré.

Gracias por el link.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Cierto que me temia una respuesta de este estilo. :)))

La leche .. cuanto me haces estudiar .. y mi jefe dice que no podemos perder
el tiempo en estudiar tanto .. jajaja

Venga .. lo miro y seguimos .. gracias!!


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com