Reglas de negocio en procedimientos almacenados Vs componentes

También debemos considerar la implementación en cada sistema. Entre Yukon y
Stinger existen diferencias importantes: Stinger no permite managed code
para todo (si no recuerdo mal, sólo lo permite para sprocs, a diferencia de
Yukon que lo permite en sproc, udfs, triggers y xsprocs). Otra diferencia
importante es que Yukon usa un in-proc provider cuando debe acceder a datos
desde managed code, es decir que no necesita salirse del proceso hacia el
.NET Framework y volver. En el caso de Stinger es ésto último, lo cual en
principio será de menor performance.

Gustavo Larriera, MVP
Uruguay LatAm
http://sqljunkies.com/weblog/gux/
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"ulises" wrote in message
news:5a5f01c4c758$bafb0900$
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 :(

...

También soy un poco escéptico a implementar sprocs o udfs o triggers
directamente en managed code. Pero me resulta interesante el uso de nuevas
funciones aggregate o de tipos de datos de .NET en la base de datos.

Y definitivamente pienso que el uso de .NET en Yukon será excelente para
escribir extended sprocs. Hoy en SQL 2000 es un arte oscuro de alquimistas
hacer eso... :-)

Gustavo Larriera, MVP
Uruguay LatAm
http://sqljunkies.com/weblog/gux/
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"Salvador Ramos" wrote in message
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

Exactemente. Creo que aquí coincidimos todos, la inclusión de Managed Code
en el servidor es una opción muy interesante. Simplemente deberemos tenerla
en cuenta y a la hora de resolver cada caso estudiar los pros y contras, y
utilizarla cuando lo creamos conveniente. El problema creo que estará en
aquellos desarrolladores que se encuentran muy cómodos trabajando con .NET y
no conocen a fondo SQL Server, creo que intentarán resolver con Managed Code
en ocasiones en que no sea necesario. Espero que se publiquen unas guías de
buenas prácticas sobre este tema.

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:

También soy un poco escéptico a implementar sprocs o udfs o triggers
directamente en managed code. Pero me resulta interesante el uso de nuevas
funciones aggregate o de tipos de datos de .NET en la base de datos.

Y definitivamente pienso que el uso de .NET en Yukon será excelente para
escribir extended sprocs. Hoy en SQL 2000 es un arte oscuro de alquimistas
hacer eso... :-)

Gustavo Larriera, MVP
Uruguay LatAm
http://sqljunkies.com/weblog/gux/
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"Salvador Ramos" wrote in message
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