Prodimientos almacenados (llevar todo ahi?)

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

On Tue, 23 Oct 2007 15:05:34 +0200, "Pablo Roca"
wrote:

Desda algun sitio tengo que decirle que cree, actualice un nuevo Cliente
(por ejemplo)

Tendria entonces clases que fueran: Cliente.Nuevo, Cliente.Borrar,
Cliente.Modificar, Clientes.Saldos ... de tal manera que la lógica de
acceder a un cliente lo hago desde mi aplicación (en C# por ejemplo), a
pesar que el trabajo de acceso lo haga SQL Server.

No les veo ninguna utilidad a esas clases.

Yo tengo una clase ClienteForm y desde allí hago todo eso usando
databindings sin necesidad de más historias.

Si quiero ver un saldo eso siempre está en una vista y no tengo más
que engancharla directamente a un "Grid" o un "TextBox".

Para modificar los datos de un cliente lo mismo.

Eso de las clases de negocio además de no ayudar en nada son un lio.
Por ejemplo si quieres ver las ventas por cliente ¿A quien se lo
pides? ¿Al objeto Ventas o al objeto Clientes?

Estas clases simplemente lo que harian seria llamar bien a sentencias SQL,
bien a Vistas, bien a Procedimientos almacenados. Creo que así queda todo
bien claro a la hora de crear y modificar código.

No hay mejor código que el que no existe. Si podemos eliminar esas
clases que no aportan valor y automatizar más usando por ejemplo
"databindings", pues mucho mejor.

Yo no conozco Fox, pero vengo de Delphi y con él se podían hacer un
montón de cosas básicas como crear, borrar y modificar registros sin
escribir una sola línea de código. Supongo que con Fox sería igual.

Lo de las "clases de negocio" es ir hacia atrás no hacia adelante.


Saludos
Alfredo

Ah, me olvidé comentarte, que la aplicación que estoy empezando a realizar
es con un Servicios Web, 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).


Saludos,

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

Gracias Carlos, muy detallada tu información.

paisano tambien? .. que bueno .. .:)


Saludos,

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

Hola Pablo :)


La pregunta que debes resolver es el coste que vas a tener que soportar para
realizar consultas entre ejercicios. Sin conocer tu aplicación, veo
problemático separar la información por bases de datos entre ejercicios.


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.


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


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 :) eso si, según vaya creciendo tu sistema, la
ventana de backup se irá haciendo más pequeña, y tal, y tal... ya sabes,
todo el tema de disponibilidad, etc.etc. en cualquier caso, el volumen de
crecimiento de tu sistema es algo que debes considerar, y normalmente las
previsiones no se suelen hacer a tiempo mayor de 15 años ahora mismo me
acuerdo de un cliente que tenía un volumen inicial de 3.5TB de base de
datos, y las previsiones para el 2017 lo ponían en torno a 12-15TB...
llegado ese momento, seguro que SQL Server se parece muy poco a lo que es en
2005; por ejemplo, ya estamos hablando que en la versión 2007 la compresión
de datos va a ser una característica muy importante...



Saludos,

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

"Pablo Roca" wrote in message
news:%

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