Prodimientos almacenados (llevar todo ahi?)

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

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.

Además en cualquier caso es mucho mejor implementar lógica de negocio
usando procedimientos almacenados CLR que hacerlo en las aplicaciones.


Saludos
Alfredo

ya .. ya .. veo que tienes razón.

Una cosa .. y guardais TODOS los ejercicios? No haceis algun proceso de
llevarse los datos de ejercicios muy antiguos a otra BBDD?

Es que a mi, por empresa ejercicio tengo como entre 600 Megas a un poco mas
de 1 Gb de datos. Tener datos de mas de 5 años hacia atrás.. pues como que
le veo poca utilidad .. y eso me sobrecargaria innecesariamente las
consultas. ¿no?


Saludos,

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

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

Bueno .. aunque me llevara toda la lógica de negocio al SGBD, pues haria
algun envoltorio que accedan a esa logica de negocio en el servidor .. sobre
todo por tener un poco de organización en la aplicación, nada más.

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

A ver . uilizo SQL, dices entonces que haga la actualización desde mi
lenguaje de programación con un sentencia SQL para cada caso? Pero no se
dice que los SP viene precompilados? que tienen muchas ventajas? eso lo
perderia

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

No los necesitas.

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

:))))))


Saludos,

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

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.

jejeje .. suena a chiste ... pero sin querer generalizar, te voy a dar un
poco de razón. :)))


Saludos,

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

Gracias Alfredo,

Tengo claro que tengo que ver mas el tema de las vistas.

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

Vaya .. ahi si que no estoy de acuerdo. Si la aplicación es para acceder
desde Internet, el traerse de cada vez la lógica de presentación puede
suponer una carga innecesaria.

En cualquier caso intenta evitar el uso de cursores.

Si, veo que le teneis una especial "mania" por aqui a ellos. :))


Saludos,

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