Prodimientos almacenados (llevar todo ahi?)

Hola,

uff, me gustaría responder a este mensaje, pero no entiendo qué quieres
decir con:

los desarrolladores del primer párrafo.

Saludos,

Eladio Rincón,
SQL Server MVP
http://blogs.solidq.com/es/elrincondeldba

"Alfredo Novoa" wrote in message
news:

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 16:44:16 +0200, "Pablo Roca"
wrote:

Ah, me olvidé comentarte, que la aplicación que estoy empezando a realizar
es con un Servicios Web

Mala cosa, pero no es el fin del mundo :-)

, y evidentemente no puedo hacer un binding de cada
control a la base de datos, lo tengo que pasar todo por una capa (llamala
como quieras capa de negocio o lo que sea).

Claro que sigues pudiendo usar databindings. Solo tendrías que
implementar una clase que descienda de IBindingList y hacer que genere
el código SQL necesario.

Te creas un servicio Web con UN método que acepte una cadena SQL y
devuelva un resultado y te ahorras un montón de problemas.

Vamos, que la idea consiste en que la capa esa no te haga perder la
productividad a la que estábamos acostumbrados antes de la moda de los
Web Services.

Mejor una clase para todo que 800 clases.


Saludos

Hola :))

Por ejemplo, ¿qué harías con los datos comunes como clientes? ¿cada bd de
ejercicio tendría una copia? ¿cual sería la válida? ¿las modificaciones de
clientes tendrían que aplicarse a cada base de datos activa? esto podrías
resolverlo con una bd común, y n bases de datos por ejercicio.

Si fuera a una bbdd por empresa-ejercicio. Si cada bbdd tendria una copia de
los clientes. la válida seria la que esté en cada ejercicio. las
modificaciones aplicarse a cada base de datos activa? no, por supuesto que
no.

db comun y nbases de datos por ejercicio? Eso no estaría mal, pero eso no da
problemas con los triggers, transacciones multi base de datos?

Desde el punto de vista de SQL Server, yo iría por una base de datos que
contenga todo, y luego, si tenéis por norma que los datos más antiguos de
5 años no se usan, diseñar procesos de archiving que muevan los datos a
otra bd a modo de repositorio... al fin y al cabo, después de cinco años
montarás unos hermosos cubos OLAP... :)

Cubos OLAP? claro que si! .. pero como te dije en otro hilo, el uso que le
daremos al data mining será muy pequeño y en contra tenemos frecuentes
accesos a los datos del ejercicio actual.

Sobre la recarga de las consultas... considera a SQL Server como algo que
te da los datos que le pides, si tus consultas no necesitan datos de antes
de cinco años, pues tiras consultas adecuadas, y los índices adecuados,
pues simplemente nunca se leerán :)

Correcto .. tengo otro problema que no dije. Sincronización de la BBDD
contra SQL Server Express. Los directivos quieren llevar la información de
la base de datos en sus portatiles.


Saludos,

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

Ah, me olvidé comentarte, que la aplicación que estoy empezando a realizar
es con un Servicios Web

Mala cosa, pero no es el fin del mundo :-)

Por lo que comentaste anteriormente ya me imaginé que los Web Services
podrian no entrar entre tus preferencias. :)))

Te creas un servicio Web con UN método que acepte una cadena SQL y
devuelva un resultado y te ahorras un montón de problemas.

jejeje

Una clase no solo tiene el acceso a datos, hay veces tiene mas lógica por
detrás. De todos modos, como lo dices no me convence, prefiero tener todo la
lógica en la parte del servidor y lo minimo posible en el cliente.


Saludos,

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

Sin ánimos de discutir quiero discrepar con eso de que "Los procedimientos
almacenados deben ser una de las últimas opciones".

Los procedimientos almacenados ofrecen el máximo rendimiento posible a una
aplicación y menor cantidad de idas al servidor... personalmente ese motivo
hace que sea una de mis primeras opciones favoritas :-)

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/profile/gux
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Carlos M. Calvelo" wrote:

Hola Pablo,

On 23 okt, 09:36, "Pablo Roca" wrote:
> 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.
>

Los procedimientos almacenados deben ser una de las últimas
opciones. Solo deberían utilizarse cuando algo no se puede
expresar de otra forma.

Veamos... las responsabilidades fundamentales del SGBD son:
1) guardar la integridad de los datos,
2) derivar datos.
3) ejecución de tareas a raíz de ciertos eventos o cambios.
[ Menos importante que 1) y 2) ]

Para 1), integridad de datos: CHECKS, (constraints).
- Excepto lo que ya se puede expresar por otros medios, claro,
como por ejemplo integridad referencial, unicidad, etc.
- Eventualmente haciendo uso de funciones.
- Lo que no se pueda expresar de esta forma irá en triggers.

Para 2), derivación de datos: VISTAS.
- Lo que no se pueda expresar en vistas, irá en procedimientos
almacenados.

Para 3), acciones a raíz de ciertos cambios: TRIGGERS.
- Ya se ha dado el ejemplo de mandar un correo electrónico.

Un par de puntos mas:
Con las herramientas de seguridad se puede forzar, por ejemplo,
que ciertos datos solo se puedan acceder o modificar por medio de
vistas o procedimientos almacenados, si eso fuera necesario para
guardar la integridad de datos.

Otro aspecto importante es tratar de pensar siempre en conjuntos
de registros a la vez, y no en un registro a la vez.
Por ejemplo, tratar de hacer algo en una consulta en vez de
meterse a cursores.

En cuanto a donde está el límite.., pues algo es responsabilidad
del SGBD (integridad, derivación de datos) o de las aplicaciones
(presentación, cálculos que solo tienen significado en la
presentación, comunicación con el usuario y el sgbd, etc.)

También se habla de 'lógica de negocio'. Lógica de negocio
ES integridad de datos, también de los datos derivados.

Saludos,
Carlos
PD: También paisano. :)