Reglas de negocio en procedimientos almacenados Vs componentes

Hola, buee este es un tema super discutible :-S

Pero veamos:

Si desarrollas para SqlServer y los procesos de reglas de negocio no son
complejas ni requieren cursores, yo las pondria en la BDD porque:

porque el tratamiento que se hace desde dentro del motor con instrucciones
T-sql son mucho mas eficientes que lo mismo desde fuera de la aplicacion, ni
hablar si se llega a llenar un Dataset del lado del cliente y se empiezan a
recorrer los registros :S

Ahora bien, tampoco es cuestion de poner todas las reglas dentro de un SP,
una gran mayoria se pueden poner sin ninguna complejidad. El tema es que los
desarrolladores si quieren programar tambien en T-sql van a tener que tener
esas habilidades tambien.

Yo en mis sistemas tengo un mix, y la metrica que uso es esta:

Si la regla de negocio no requiere de procesos y calculos complejos (ni
mucho menos de cursores), entonces lo hago dentro de SP, ahora si la regla
requiere calculos complejos o hasta la utilizacion de cursores, entonces lo
pongo fuera del motor.

Pero por ej:

Dentro de un SP de CRUD, se puede poner una regla de negocio y eso es solo
T-sql simple (segun el caso).

Tambien hay que remarcar que los SP no solo son utiles a nivel de
performance sino de seguridad!! y un factor que muy pocos conocen quizas:

Si pones todo fuuera y un dia llega a cambiar la extructura de la BDD (por
ej un campo) se va a ser complicado buscar en que procesos afecta eso, ahora
si esto esta dentro de un SP es una tarea muy simple de verdad :-)


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Vym System" <Vym escribió en el mensaje
news:

Hola foro, estoy en una empresa donde se esta discutiendo el tema en
cuestion.

Los arquitectos de la misma quieren implementar las politicas de negocio
fuera del motor de BDD (todas las politicas) y a mi en lo personal esa
idea
no me gusta mucho ya que por lo que he visto y probado, se pierde mucha
performance.

Me gustaria saber vuestras opiniones para poder saber que hacen ustedes!

gracias

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.788 / Virus Database: 533 - Release Date: 01/11/2004

Hola Salvador, mis comentarios entre líneas...

"Salvador Ramos" wrote in message
news:%

Aunque quería hacer una puntualización. Creo que una solución intermedia,
donde haya parte de la lógica de negocio en la capa de negocios, y otra
parte en la base de datos (utilizaría esta opción cuando necesitase
realizar un proceso que requiera mucho acceso a datos, y cálculos no
excesivamente complejos).

Creo que en estos casos no es bueno una solución extrema, ni todo en la
capa de negocios, ni todo en la capa de datos. Por supuesto parto de que
siempre se utilizará SQL Server, ya que si se quiere que la aplicación
funciones en distintos gestores de bases de datos, complica el tener
código en la base de datos.

Coincido en la solución intermedia.

En lo que respecta a aplicaciones que deben ser independientes del gestor de
bases de datos, el código en la base de datos, especialmente stored
procedures y triggers, tiene el problema de la poca portabilidad de un
dialecto a otro. Estoy siguiendo de cerca una migración de código de PL/SQL
Oracle a T-SQL de SQL Server y la tarea es sumamente compleja y casi
totalmente manual, leyendo linea a linea el código :-(

Ahora quisiera traer la cuestión de SQL Server 2005, donde el uso de .NET
nivela la programación en la base con la de la capa media. Enfoque parecido
que ha seguido DB2 Stinger... creo que eso va a cambiar mucho este tipo de
decisiones que estamos conversando en este hilo.

Un saludo
Salvador Ramos
Murcia - España

Muchísimos saludos,
gux

Hola Gustavo, yo también he participado en alguna migración, y efectivamente
es todo manual, es más hay que analizar de nuevo algunas partes del código
totalmente.

En la segunda cuestión también coincido contigo, pero como DBA me plantearía
muy seriamente la introducción de código .NET en una base de datos. No digo
que no la admita, al contrario, me alegro mucho de que exista esa
posibilidad, sino que debería estar muy justificada.

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net
¿ Te interesa participar en las reuniones
del grupo de Usuarios de SQL Server y .NET ?
Se harán en levante de España, (Alicante o Murcia)?

"Gustavo Larriera [MVP]" escribió en el mensaje
news:

Hola Salvador, mis comentarios entre líneas...

"Salvador Ramos" wrote in message
news:%

Aunque quería hacer una puntualización. Creo que una solución intermedia,
donde haya parte de la lógica de negocio en la capa de negocios, y otra
parte en la base de datos (utilizaría esta opción cuando necesitase
realizar un proceso que requiera mucho acceso a datos, y cálculos no
excesivamente complejos).

Creo que en estos casos no es bueno una solución extrema, ni todo en la
capa de negocios, ni todo en la capa de datos. Por supuesto parto de que
siempre se utilizará SQL Server, ya que si se quiere que la aplicación
funciones en distintos gestores de bases de datos, complica el tener
código en la base de datos.

Coincido en la solución intermedia.

En lo que respecta a aplicaciones que deben ser independientes del gestor
de bases de datos, el código en la base de datos, especialmente stored
procedures y triggers, tiene el problema de la poca portabilidad de un
dialecto a otro. Estoy siguiendo de cerca una migración de código de
PL/SQL Oracle a T-SQL de SQL Server y la tarea es sumamente compleja y
casi totalmente manual, leyendo linea a linea el código :-(

Ahora quisiera traer la cuestión de SQL Server 2005, donde el uso de .NET
nivela la programación en la base con la de la capa media. Enfoque
parecido que ha seguido DB2 Stinger... creo que eso va a cambiar mucho
este tipo de decisiones que estamos conversando en este hilo.

Un saludo
Salvador Ramos
Murcia - España

Muchísimos saludos,
gux

Hola Savador y Gux!!

Es cierto que Yukon tendra la posibilidad de meter codigo .net dentro de
nuestro motor (ya sea por medio de SP o cualquier otra cuestion)

Yo francamente no lo meteria, por lo menos hasta donde probe no es nada
eficiente eso :(

Creo que cada cosa deberia ir en su lugar, para mi el proceso de los datos
los deberia hacer la capa de datos y poner proceso de datos fuera de la capa
de datos se justifica si se necesitan hacer cosas que T-sql no pueda
resolver en primer instancia.

Ahora hay muchas pero muchas reglas de negocio que son solo simple INSERT y
SELECT, por ej:

Si cuando emito una factura debo descontar el Stock del articulo, yo ahi lo
estudiaria un poco el tema ;), lo unico que gano escribiendo esto fuera de
la BDD es no depender de un motor pero eso tiene su precio claro ;), en cada
caso habra que analizar costo - beneficio a ver que resulta :)


Salu2
Maxi
Buenos Aires - Argentina
Desarrollador Microsoft 3 Estrellas .NET
Nunca consideres el estudio como una obligación sino como
una oportunidad para penetrar en el bello y maravillosos
mundo del saber.
- Albert Einstein



"Salvador Ramos" escribió en el
mensaje news:

Hola Gustavo, yo también he participado en alguna migración, y
efectivamente es todo manual, es más hay que analizar de nuevo algunas
partes del código totalmente.

En la segunda cuestión también coincido contigo, pero como DBA me
plantearía muy seriamente la introducción de código .NET en una base de
datos. No digo que no la admita, al contrario, me alegro mucho de que
exista esa posibilidad, sino que debería estar muy justificada.

Un saludo
Salvador Ramos
Murcia - España
[Microsoft MVP SQL Server]
www.helpdna.net
¿ Te interesa participar en las reuniones
del grupo de Usuarios de SQL Server y .NET ?
Se harán en levante de España, (Alicante o Murcia)?

"Gustavo Larriera [MVP]" escribió en el mensaje
news:

Hola Salvador, mis comentarios entre líneas...

"Salvador Ramos" wrote in message
news:%

Aunque quería hacer una puntualización. Creo que una solución
intermedia, donde haya parte de la lógica de negocio en la capa de
negocios, y otra parte en la base de datos (utilizaría esta opción
cuando necesitase realizar un proceso que requiera mucho acceso a datos,
y cálculos no excesivamente complejos).

Creo que en estos casos no es bueno una solución extrema, ni todo en la
capa de negocios, ni todo en la capa de datos. Por supuesto parto de que
siempre se utilizará SQL Server, ya que si se quiere que la aplicación
funciones en distintos gestores de bases de datos, complica el tener
código en la base de datos.

Coincido en la solución intermedia.

En lo que respecta a aplicaciones que deben ser independientes del gestor
de bases de datos, el código en la base de datos, especialmente stored
procedures y triggers, tiene el problema de la poca portabilidad de un
dialecto a otro. Estoy siguiendo de cerca una migración de código de
PL/SQL Oracle a T-SQL de SQL Server y la tarea es sumamente compleja y
casi totalmente manual, leyendo linea a linea el código :-(

Ahora quisiera traer la cuestión de SQL Server 2005, donde el uso de .NET
nivela la programación en la base con la de la capa media. Enfoque
parecido que ha seguido DB2 Stinger... creo que eso va a cambiar mucho
este tipo de decisiones que estamos conversando en este hilo.

Un saludo
Salvador Ramos
Murcia - España

Muchísimos saludos,
gux

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.788 / Virus Database: 533 - Release Date: 01/11/2004

De acuerdo con Salvador y Maxi, todavía estoy muy escéptico
a la forma de manejo de los assemblies dentro de Yukon y
Stinger, si no me equivoco Oracle ya podía incorporar
código Java dentro de la BD y no tuvo mayor aceptación
tanto que creo qye ya se quitó esa opción en 10g.

Saludos,
Ulises

Hola Savador y Gux!!

Es cierto que Yukon tendra la posibilidad de meter codigo

.net dentro de

nuestro motor (ya sea por medio de SP o cualquier otra

cuestion)

Yo francamente no lo meteria, por lo menos hasta donde

probe no es nada

eficiente eso :(

...