Prodimientos almacenados (llevar todo ahi?)

On Tue, 23 Oct 2007 09:36:46 +0200, "Pablo Roca"
wrote:

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

No tanto como las vistas.

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?

Solo lo que no puedas hacer con vistas. Yo los uso muy poco por que
hay muy pocas cosas que no se puedan hacer con vistas en un sistema de
gestión.

En cualquier caso intenta evitar el uso de cursores.

¿Donde está el limite?

En las cosas que no son lógica de negocio, como por ejemplo la lógica
de presentación que debe de ir en las aplicaciones. Aunque tampoco
está nada mal almacenar la configuración de la lógica de presentación
en tablas de la base de datos.


Saludos
Alfredo

On Tue, 23 Oct 2007 10:21:38 +0200, "Salvador Ramos"
wrote:

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.

Nunca está mal conocer las opiniones de todo el mundo, pero no hay que
olvidar que la mayoría de los desarrolladores no tienen ni idea de
bases de datos y por lo tanto no hay que tener sus opiniones muy en
cuenta en estos casos.

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.

No lo entiendo T-SQL está mucho mejor preparado para implementar
lógica de negocio compleja que los lenguajes de programación de
aplicaciones.

La regla general es implementar TODA la lógica de negocio en el SGBD,
excepto en los casos en los que no sea posible debido a las
limitaciones del SGBD particular que estés usando.

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

La generación de código es un síntoma de mal diseño.

http://c2.com/cgi/wiki?CodeGenerati...esignSmell



Saludos
Alfredo

On Tue, 23 Oct 2007 11:03:00 +0200, "Pablo Roca"
wrote:

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 :))

Exacto.

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.

¿Para que quieres una "capa de negocio" en las aplicaciones si ya
tienes toda la lógica de negocio asegurada por el SGBD?

Lo de las "capas de negocio" es una tontería de los desarrolladores
del primer párrafo.

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?

¡No, no, no, no, no!

Eso es una pérdida de tiempo increible. Necesitarías los 800 SP que no
sirven para nada solo para empezar y a partir de ahí lo mismo para
cada consulta y para cada informe.

Para actualizar la base de datos usas SQL que para eso está y no hagas
caso a los desarrolladores del primer párrafo.

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

No los necesitas.

http://c2.com/cgi/wiki?CodeGenerati...esignSmell



Saludos

On Tue, 23 Oct 2007 12:28:13 +0200, "Salvador Ramos"
wrote:

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

Por qué una base de datos por empresa y ejercicio ???

Por que es una forma cutre pero efectiva de "particionar" los datos
cuando usas un SGBD que no es bueno haciendo esto mismo.


Saludos
Alfredo

On Tue, 23 Oct 2007 13:36:28 +0200, Alfredo Novoa
wrote:

On Tue, 23 Oct 2007 12:28:13 +0200, "Salvador Ramos"
wrote:

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

Por qué una base de datos por empresa y ejercicio ???

Por que es una forma cutre pero efectiva de "particionar" los datos
cuando usas un SGBD que no es bueno haciendo esto mismo.

No me fijé en lo del ejercicio.

Lo de tener una base de datos distinta por cada ejercicio si que es
una gran fuente de problemas por que es muy normal que haya consultas
"multiejercicio". Es una idea muy mala.


Saludos
Alfredo