Prodimientos almacenados (llevar todo ahi?)

A mi esto me sorprendió bastante.


Saludos,

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

Coincido plenamente contigo, sin dejar de mencionar que los SP tambien
ayudan a la seguridad (nos dan una capa de abstraccion mas para no acceder a
los objetos de forma directa) y tambien al mantenimiento, si hay que tocar
se toca ahi solo y no en todas las aplicaciones, y para las migraciones
tener el codigo en sql es mucho mejor que fuera, ya que el upgrate advisor
de la otra manera deberia funcionar con una traza y deberiamos certificar
que en esa traza existan todos los procesos de todos los sistemas (algo muy
complicado de por si) haciendo q las migraciones puedan durar mucho mas
tiempo (se traduce en mas dinero)


-
Microsoft M.V.P en SQLServer
SQLTotal Consulting - Servicios en SQLServer
Email:
"Gux (MVP)" escribió en el mensaje
news:

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

Este buen artículo del MVP Brad McGehee es recomendado:

SQL Server Performance Tuning for Stored Procedures
http://www.sql-server-performance.c...es_p1.aspx

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



"Pablo Roca" wrote:

A mi esto me sorprendió bastante.


Saludos,

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

Gracias Gustavo


Saludos,

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

On Tue, 23 Oct 2007 17:58:48 +0200, "Pablo Roca"
wrote:

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.

Si hay más cosas pues te creas más métodos, pero toda la gestión de
datos la puedes hacer con un único método que tenga como parámetro una
cadena SQL. Y con eso te quitas un gran peso de encima.

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.

Yo igual. De esa forma toda la lógica estaría en el servidor.

Lo que digo es algo como hacer un proveedor ADO.NET que funcione a
través de tu Web Service, así no te enterarías si estás usando Web
Services, una conexión de red local, o cualquier otra cosa.


Saludos
Alfredo