Reglas de empresa sobre capa de Datos.

Pues yo no lo haría ni con triggers ni con restricciones a la tabla,
sino que toda esa lógica la metería dentro del procedimiento almacenado y
que todo acceso a las tablas (lectura y modificaciones) se hiciera a través
de ellos (dando permisos de ejecución únicamente a los susodichos
procedimientos).

Personalmente creo que meter la lógica (bueno, todo depende, porque
validar rango de valores es mejor hacerlo por ejemplo en un CHECK) en
triggers lo que hace es ofuscar un poco todo y complicarte la vida...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Marcelo Clavero" escribió en el mensaje
news:

Estimados Todos:

Estoy haciendo una aplicación con alrededor de unas 300 tablas y transito

la

etapa de escribir las reglas de empresa.
Antes casi todo lo hacía desde la capa de aplicación (salvo relaciones y
desencadenadores simples), pero esta vez, opté por darle más lógica a la
capa de datos, y asegurar la integridad desde los cimientos, dejando que

el

ASP.NET solo mande ejecutar SP's y se encargue de embellecer la interfase
del usuario. Espero haber optado bien, ya que el tiempo apremia, y domino
muy poco el T-SQL. (el simple hecho de pensar en grupos de datos y no en
cursores, ya me da su trabajillo).-

Bueno, para escribir las reglas, uso UDFs colocadas en restricciones (tal
como me aconsejaron aquí en el grupo), lo cual me ayudó a resolver varias
situaciones ya. Pero me topé con un aspecto inesperado. Al intentar
modificar UDFs cuando ya están referidas desde alguna restriccion Check de
alguna (o varias) tablas, el SQL manda error de que no se puede hacer el
ALTER FUNCTION.

Entonces, cada vez que necesito cambiar o agregar código (así sea una

línea

de comentario) de una UDF ya referida, voy torpemente a cada tabla que la
refiere, borro la restricción, vuelvo a la UDF, hago la modificación y

luego

vuelvo a cada tabla y re-escribo la llamada a la UDF (que con suerte no se
ha ido del portapapeles). (uffff). - jajaja...que torpeza la mía !!!.
¿ Se puede evitar hacer toooodo eso ?

Y para terminar (espero no abusar de vuestra amabilidad), pregunto: ¿ voy
bien usando UDFs en las restricciones o mejor usar triggers ?? o depende

el

caso ? No capto aun la diferencia si bien vislumbro gran potencia en ambas
herramientas.

Gracias desde ya.
Mis respetos,
Marcelo

Hola, a ver, creo que debemos separar un poco los tantos: para mi una
restriccion check no es parte de una regla de negocios sino de integridad de
datos :-), esto lo aclaro porque hay mucha confusion con este tipo de cosas,
hasta he oido que el tipo de datos es una regla de negocios ;-)

Bien, reglas de negocios, se pueden hacer de varias maneras, lo ideal seria
sacarlas del servidor y hacerlas en la capa de negocios, pero tampoco hay
que ser blanco o negro, hay muchas reglas que son muy simples de hacer con
TSQL con lo cual es mucho mejor hacerlas ahi.

Yo como regla tengo: Si la regla de negocio es simple la hago en TSQL si es
compleja utilizo la capa correspondiente (debo aclarar que mis desarrollos
son siempre hacia un motor de base de datos y en su mayoria sqlserver :-)


Salu2
Maxi


"Marcelo Clavero" escribió en el mensaje
news:

Estimados Todos:

Estoy haciendo una aplicación con alrededor de unas 300 tablas y transito
la
etapa de escribir las reglas de empresa.
Antes casi todo lo hacía desde la capa de aplicación (salvo relaciones y
desencadenadores simples), pero esta vez, opté por darle más lógica a la
capa de datos, y asegurar la integridad desde los cimientos, dejando que
el
ASP.NET solo mande ejecutar SP's y se encargue de embellecer la interfase
del usuario. Espero haber optado bien, ya que el tiempo apremia, y domino
muy poco el T-SQL. (el simple hecho de pensar en grupos de datos y no en
cursores, ya me da su trabajillo).-

Bueno, para escribir las reglas, uso UDFs colocadas en restricciones (tal
como me aconsejaron aquí en el grupo), lo cual me ayudó a resolver varias
situaciones ya. Pero me topé con un aspecto inesperado. Al intentar
modificar UDFs cuando ya están referidas desde alguna restriccion Check de
alguna (o varias) tablas, el SQL manda error de que no se puede hacer el
ALTER FUNCTION.

Entonces, cada vez que necesito cambiar o agregar código (así sea una
línea
de comentario) de una UDF ya referida, voy torpemente a cada tabla que la
refiere, borro la restricción, vuelvo a la UDF, hago la modificación y
luego
vuelvo a cada tabla y re-escribo la llamada a la UDF (que con suerte no se
ha ido del portapapeles). (uffff). - jajaja...que torpeza la mía !!!.
¿ Se puede evitar hacer toooodo eso ?

Y para terminar (espero no abusar de vuestra amabilidad), pregunto: ¿ voy
bien usando UDFs en las restricciones o mejor usar triggers ?? o depende
el
caso ? No capto aun la diferencia si bien vislumbro gran potencia en ambas
herramientas.

Gracias desde ya.
Mis respetos,
Marcelo

Gracias a ambosveo que estoy sobre un tema un poco delicado.

Tendré muy en cuenta lo de los Procs Almacenados que sugiere Carlos, y meter
allí lo más que pueda que implique movimiento de tablas. Claro que
restricciones simples, tal como una validación de rango, o alguna reglita de
integridad, como por ejemplo comprobar existencia de un dato en otras tablas
sobre campos que no son ni PK ni UNIque (como me indicó Alejandro en una
respuesta previa), bien vale meterlas en restricciones con UDFs dentro y no
aparenta tan complicado.

En cuanto a lo que comenta Maxi, me confundo facilmente entre lo que es
lógica de negocio y lo que es integridad, pues los veo como que por momentos
se pisan, si bien no son lo mismo, claro. Por ejemplo "Un cliente puede
tener cero, 1, o muchos corredores asociados, pero si el tipo de cliente es
"Tal", solo puede haber 1 corredor y solo 1". Esta es una regla de negocio,
¿ no ? que para asegurar la integridad, debo restringir condicionalmente los
ingresos a la tabla "Corredores por Cliente"...ya sea con Checks, con SP
(como recomienda Carlos) o en una capa de negocio como dice Maxi. .
Ahora, suponiendo el caso que no defino la regla sobre la BD, y que luego
necesito hacer una manipulacion con el EM directo sobre SQL, ¿ no sería
facil infringir la regla desde allí y perder integridad ? ¿ toy muy
errado ?. Disculpen mi ignorancia.

PD. Si pueden por favor coméntenme ¿ por qué el SQL manda ese mensaje de
error que no se puede cambiar una función si está asociada a una restricción
??...es correcto que sea así, ¿ hay forma de evitarlo ???.

10000 Gracias por ser tan amables, espero no estar abusando de ustedes.
Marcelo




"Maxi" escribió en el mensaje
news:u7b#

Hola, a ver, creo que debemos separar un poco los tantos: para mi una
restriccion check no es parte de una regla de negocios sino de integridad

de

datos :-), esto lo aclaro porque hay mucha confusion con este tipo de

cosas,

hasta he oido que el tipo de datos es una regla de negocios ;-)

Bien, reglas de negocios, se pueden hacer de varias maneras, lo ideal

seria

sacarlas del servidor y hacerlas en la capa de negocios, pero tampoco hay
que ser blanco o negro, hay muchas reglas que son muy simples de hacer con
TSQL con lo cual es mucho mejor hacerlas ahi.

Yo como regla tengo: Si la regla de negocio es simple la hago en TSQL si

es

compleja utilizo la capa correspondiente (debo aclarar que mis desarrollos
son siempre hacia un motor de base de datos y en su mayoria sqlserver :-)


Salu2
Maxi


"Marcelo Clavero" escribió en el mensaje
news:
> Estimados Todos:
>
> Estoy haciendo una aplicación con alrededor de unas 300 tablas y

transito

> la
> etapa de escribir las reglas de empresa.
> Antes casi todo lo hacía desde la capa de aplicación (salvo relaciones y
> desencadenadores simples), pero esta vez, opté por darle más lógica a la
> capa de datos, y asegurar la integridad desde los cimientos, dejando que
> el
> ASP.NET solo mande ejecutar SP's y se encargue de embellecer la

interfase

> del usuario. Espero haber optado bien, ya que el tiempo apremia, y

domino

> muy poco el T-SQL. (el simple hecho de pensar en grupos de datos y no en
> cursores, ya me da su trabajillo).-
>
> Bueno, para escribir las reglas, uso UDFs colocadas en restricciones

(tal

> como me aconsejaron aquí en el grupo), lo cual me ayudó a resolver

varias

> situaciones ya. Pero me topé con un aspecto inesperado. Al intentar
> modificar UDFs cuando ya están referidas desde alguna restriccion Check

de

> alguna (o varias) tablas, el SQL manda error de que no se puede hacer el
> ALTER FUNCTION.
>
> Entonces, cada vez que necesito cambiar o agregar código (así sea una
> línea
> de comentario) de una UDF ya referida, voy torpemente a cada tabla que

la

> refiere, borro la restricción, vuelvo a la UDF, hago la modificación y
> luego
> vuelvo a cada tabla y re-escribo la llamada a la UDF (que con suerte no

se

> ha ido del portapapeles). (uffff). - jajaja...que torpeza la mía !!!.
> ¿ Se puede evitar hacer toooodo eso ?
>
> Y para terminar (espero no abusar de vuestra amabilidad), pregunto: ¿

voy

> bien usando UDFs en las restricciones o mejor usar triggers ?? o depende
> el
> caso ? No capto aun la diferencia si bien vislumbro gran potencia en

ambas

> herramientas.
>
> Gracias desde ya.
> Mis respetos,
> Marcelo
>
>

Hola Marcelo, estas entrando en tema delicado como has mencionado.

Mira antes de definir bien las reglas debes definir otras cosas no
funcionales (llamado arquitectura ;-)

por ej:

- A la base de datos solo la usara el sistema o tambien otros procesos
- Siempre trabajas con bases de datos tipo Sql u Oracle?
- La performance que tan importante es?
- La escalabilidad?
- El mantenimiento?
- Sera un sistema homogeneo o no?

Si la regla esta en el Sp's la ventaja que tienes es que de cualquier lado
siempre se podra usar, si usas componentes no es tan directo la cosa,
tambien debes tener en consideracion algunas cosas por ej

Se usaran procesos en batch como por ej DTS o BCP? de ser asi las reglas en
los Sp's son mas complicadas de usar y tendras que ir a otro tipo de regla
como por ej UDF y Check!! buee como veras no hay una sola solucion sino que
muchas ;-)

Lo que tenes que tener bien en claro es que TSQL esta pensado para trabajar
con datos y no es un lenguaje de programacion como C# o VB.NET, entonces lo
que puedas hacer en TSQL y no sea complicado ni tenga miles de lineas hazlo
ahi, ganaras mucho en performance.

Un abrazo


Salu2
Maxi


"Marcelo Clavero" escribió en el mensaje
news:exO%

Gracias a ambosveo que estoy sobre un tema un poco delicado.

Tendré muy en cuenta lo de los Procs Almacenados que sugiere Carlos, y
meter
allí lo más que pueda que implique movimiento de tablas. Claro que
restricciones simples, tal como una validación de rango, o alguna reglita
de
integridad, como por ejemplo comprobar existencia de un dato en otras
tablas
sobre campos que no son ni PK ni UNIque (como me indicó Alejandro en una
respuesta previa), bien vale meterlas en restricciones con UDFs dentro y
no
aparenta tan complicado.

En cuanto a lo que comenta Maxi, me confundo facilmente entre lo que es
lógica de negocio y lo que es integridad, pues los veo como que por
momentos
se pisan, si bien no son lo mismo, claro. Por ejemplo "Un cliente puede
tener cero, 1, o muchos corredores asociados, pero si el tipo de cliente
es
"Tal", solo puede haber 1 corredor y solo 1". Esta es una regla de
negocio,
¿ no ? que para asegurar la integridad, debo restringir condicionalmente
los
ingresos a la tabla "Corredores por Cliente"...ya sea con Checks, con SP
(como recomienda Carlos) o en una capa de negocio como dice Maxi. .
Ahora, suponiendo el caso que no defino la regla sobre la BD, y que luego
necesito hacer una manipulacion con el EM directo sobre SQL, ¿ no sería
facil infringir la regla desde allí y perder integridad ? ¿ toy muy
errado ?. Disculpen mi ignorancia.

PD. Si pueden por favor coméntenme ¿ por qué el SQL manda ese mensaje de
error que no se puede cambiar una función si está asociada a una
restricción
??...es correcto que sea así, ¿ hay forma de evitarlo ???.

10000 Gracias por ser tan amables, espero no estar abusando de ustedes.
Marcelo




"Maxi" escribió en el mensaje
news:u7b#

Hola, a ver, creo que debemos separar un poco los tantos: para mi una
restriccion check no es parte de una regla de negocios sino de integridad

de

datos :-), esto lo aclaro porque hay mucha confusion con este tipo de

cosas,

hasta he oido que el tipo de datos es una regla de negocios ;-)

Bien, reglas de negocios, se pueden hacer de varias maneras, lo ideal

seria

sacarlas del servidor y hacerlas en la capa de negocios, pero tampoco hay
que ser blanco o negro, hay muchas reglas que son muy simples de hacer
con
TSQL con lo cual es mucho mejor hacerlas ahi.

Yo como regla tengo: Si la regla de negocio es simple la hago en TSQL si

es

compleja utilizo la capa correspondiente (debo aclarar que mis
desarrollos
son siempre hacia un motor de base de datos y en su mayoria sqlserver :-)


Salu2
Maxi


"Marcelo Clavero" escribió en el mensaje
news:
> Estimados Todos:
>
> Estoy haciendo una aplicación con alrededor de unas 300 tablas y

transito

> la
> etapa de escribir las reglas de empresa.
> Antes casi todo lo hacía desde la capa de aplicación (salvo relaciones
> y
> desencadenadores simples), pero esta vez, opté por darle más lógica a
> la
> capa de datos, y asegurar la integridad desde los cimientos, dejando
> que
> el
> ASP.NET solo mande ejecutar SP's y se encargue de embellecer la

interfase

> del usuario. Espero haber optado bien, ya que el tiempo apremia, y

domino

> muy poco el T-SQL. (el simple hecho de pensar en grupos de datos y no
> en
> cursores, ya me da su trabajillo).-
>
> Bueno, para escribir las reglas, uso UDFs colocadas en restricciones

(tal

> como me aconsejaron aquí en el grupo), lo cual me ayudó a resolver

varias

> situaciones ya. Pero me topé con un aspecto inesperado. Al intentar
> modificar UDFs cuando ya están referidas desde alguna restriccion Check

de

> alguna (o varias) tablas, el SQL manda error de que no se puede hacer
> el
> ALTER FUNCTION.
>
> Entonces, cada vez que necesito cambiar o agregar código (así sea una
> línea
> de comentario) de una UDF ya referida, voy torpemente a cada tabla que

la

> refiere, borro la restricción, vuelvo a la UDF, hago la modificación y
> luego
> vuelvo a cada tabla y re-escribo la llamada a la UDF (que con suerte no

se

> ha ido del portapapeles). (uffff). - jajaja...que torpeza la mía !!!.
> ¿ Se puede evitar hacer toooodo eso ?
>
> Y para terminar (espero no abusar de vuestra amabilidad), pregunto: ¿

voy

> bien usando UDFs en las restricciones o mejor usar triggers ?? o
> depende
> el
> caso ? No capto aun la diferencia si bien vislumbro gran potencia en

ambas

> herramientas.
>
> Gracias desde ya.
> Mis respetos,
> Marcelo
>
>

Gracias Maxi

He respondido tus preguntas y las publico aquí solo por si tienen algo que
acotar al tema, si bien ya han sido de mucha ayuda. Espero sirva a otros
también este hilo.

- A la base de datos solo la usara el sistema o tambien otros procesos.

Solo el sistema de aplicación, y eventualmente se podrían hacer algunos
mantenimientos de datos directamente sobre la base con EM, pero seré yo
mismo quien lo haga si fuera necesario. No habrá otros sonsumidores.

- Siempre trabajas con bases de datos tipo Sql u Oracle?

Solo SQL.

- La performance que tan importante es? > - La escalabilidad? -

Debería estar balanceada con la escalabilidad (leí un hilo sin desperdicio
donde tu intervenías en un debate sobre hasta donde la escalabilidad y hasta
donde la performance, otro punto delicado y muy interesante).-
Coinicido con la conclusión a la que Uds. llegaron, optando por un balance
entre ambos, con tendencia a mayor performance que escalabilidad si hubiera
que elegir, especialmente en los procesos de tiempo real. Prefiero escribir
más código que hacer que el usuario espere horas por un procedimiento
"supuestamente escalable".

- El mantenimiento? -

No todo lo dejo accesible sobre la capa de aplicación. Por ejemplo ABMs de
tablas muy poco dinámicas, los dejo sin hacer y las mantengo directo con el
EM (más que nada por un tema de falta de tiempo para desarrollo, por eso
insisto en dejar bien cimentada la integridad desde la BD, algo que me
ayudará sea desde donde sea que acceda).
En cuanto a tema de respaldos, debe haber uno diario desatendido fuera de
horario de trabajo (las bases no tienen tráfico durante la noche), y tengo
pensado ir depurando el tamaño con un desagote sobre un subsistema de
histórico. (que ya no necesitará respaldo diario, y optimizará la parte más
consultada de la base). No serán bases con un crecimiento muy abrupto.

- Sera un sistema homogeneo o no?

Si. Todo los clientes con IE, Win XP, servidores W2k3 con SQL SE, y el
ámbito es solo Intranet (sin necesidad de publicar datos, ni permitir
accesos remotos), con seguridad integrada, y toda la capa de aplicación en
ASP.NET. Relativamente sencillo y seguro el entorno.

Se usaran procesos en batch como por ej DTS o BCP?

Unos pocos procesos con Proveedores externos, necesitarán importar/ exportar
desde y hasta Excel, XML y/o texto delimitado, la mayoría de los cuales,
pueden hacerse en procesos automáticos fuera de la hora crítica de tráfico
hacia la Base, y no está pensado que los datos externos sean extraídos
remotamente, sino que tendremos en forma local, los archivos de los cuales
importar. (los mandan por mail y los colocamos en un repositorio). Hay solo
un caso de WebService que me están planteando consumir sobre un server
remoto externo a la red corporativa. Espero que sea simple desarrollar estos
DTSs y el consumible del WebService.

-

En fin, no quise aburrir, solo exponer este caso de estudio, ya que no debo
ser el único que está desarrollando algo similar y creo que este
cuestionario guiado por Maxi resultó muy instructivo.

Tal vez Maxi quiera ponerle la guinda a esta torta.

GRACIAS de corazón.
Marcelo


"Maxi" escribió en el mensaje
news:

Hola Marcelo, estas entrando en tema delicado como has mencionado.

Mira antes de definir bien las reglas debes definir otras cosas no
funcionales (llamado arquitectura ;-)

por ej:

- A la base de datos solo la usara el sistema o tambien otros procesos
- Siempre trabajas con bases de datos tipo Sql u Oracle?
- La performance que tan importante es?
- La escalabilidad?
- El mantenimiento?
- Sera un sistema homogeneo o no?

Si la regla esta en el Sp's la ventaja que tienes es que de cualquier lado
siempre se podra usar, si usas componentes no es tan directo la cosa,
tambien debes tener en consideracion algunas cosas por ej

Se usaran procesos en batch como por ej DTS o BCP? de ser asi las reglas

en

los Sp's son mas complicadas de usar y tendras que ir a otro tipo de regla
como por ej UDF y Check!! buee como veras no hay una sola solucion sino

que

muchas ;-)

Lo que tenes que tener bien en claro es que TSQL esta pensado para

trabajar

con datos y no es un lenguaje de programacion como C# o VB.NET, entonces

lo

que puedas hacer en TSQL y no sea complicado ni tenga miles de lineas

hazlo

ahi, ganaras mucho en performance.

Un abrazo


Salu2
Maxi


"Marcelo Clavero" escribió en el mensaje
news:exO%
> Gracias a ambosveo que estoy sobre un tema un poco delicado.
>
> Tendré muy en cuenta lo de los Procs Almacenados que sugiere Carlos, y
> meter
> allí lo más que pueda que implique movimiento de tablas. Claro que
> restricciones simples, tal como una validación de rango, o alguna

reglita

> de
> integridad, como por ejemplo comprobar existencia de un dato en otras
> tablas
> sobre campos que no son ni PK ni UNIque (como me indicó Alejandro en una
> respuesta previa), bien vale meterlas en restricciones con UDFs dentro y
> no
> aparenta tan complicado.
>
> En cuanto a lo que comenta Maxi, me confundo facilmente entre lo que es
> lógica de negocio y lo que es integridad, pues los veo como que por
> momentos
> se pisan, si bien no son lo mismo, claro. Por ejemplo "Un cliente puede
> tener cero, 1, o muchos corredores asociados, pero si el tipo de cliente
> es
> "Tal", solo puede haber 1 corredor y solo 1". Esta es una regla de
> negocio,
> ¿ no ? que para asegurar la integridad, debo restringir condicionalmente
> los
> ingresos a la tabla "Corredores por Cliente"...ya sea con Checks, con SP
> (como recomienda Carlos) o en una capa de negocio como dice Maxi. .
> Ahora, suponiendo el caso que no defino la regla sobre la BD, y que

luego

> necesito hacer una manipulacion con el EM directo sobre SQL, ¿ no sería
> facil infringir la regla desde allí y perder integridad ? ¿ toy muy
> errado ?. Disculpen mi ignorancia.
>
> PD. Si pueden por favor coméntenme ¿ por qué el SQL manda ese mensaje de
> error que no se puede cambiar una función si está asociada a una
> restricción
> ??...es correcto que sea así, ¿ hay forma de evitarlo ???.
>
> 10000 Gracias por ser tan amables, espero no estar abusando de ustedes.
> Marcelo
>
>
>
>
> "Maxi" escribió en el mensaje
> news:u7b#
>> Hola, a ver, creo que debemos separar un poco los tantos: para mi una
>> restriccion check no es parte de una regla de negocios sino de

integridad

> de
>> datos :-), esto lo aclaro porque hay mucha confusion con este tipo de
> cosas,
>> hasta he oido que el tipo de datos es una regla de negocios ;-)
>>
>> Bien, reglas de negocios, se pueden hacer de varias maneras, lo ideal
> seria
>> sacarlas del servidor y hacerlas en la capa de negocios, pero tampoco

hay

>> que ser blanco o negro, hay muchas reglas que son muy simples de hacer
>> con
>> TSQL con lo cual es mucho mejor hacerlas ahi.
>>
>> Yo como regla tengo: Si la regla de negocio es simple la hago en TSQL

si

> es
>> compleja utilizo la capa correspondiente (debo aclarar que mis
>> desarrollos
>> son siempre hacia un motor de base de datos y en su mayoria sqlserver

:-)

>>
>>
>> Salu2
>> Maxi
>>
>>
>> "Marcelo Clavero" escribió en el mensaje
>> news:
>> > Estimados Todos:
>> >
>> > Estoy haciendo una aplicación con alrededor de unas 300 tablas y
> transito
>> > la
>> > etapa de escribir las reglas de empresa.
>> > Antes casi todo lo hacía desde la capa de aplicación (salvo

relaciones

>> > y
>> > desencadenadores simples), pero esta vez, opté por darle más lógica a
>> > la
>> > capa de datos, y asegurar la integridad desde los cimientos, dejando
>> > que
>> > el
>> > ASP.NET solo mande ejecutar SP's y se encargue de embellecer la
> interfase
>> > del usuario. Espero haber optado bien, ya que el tiempo apremia, y
> domino
>> > muy poco el T-SQL. (el simple hecho de pensar en grupos de datos y no
>> > en
>> > cursores, ya me da su trabajillo).-
>> >
>> > Bueno, para escribir las reglas, uso UDFs colocadas en restricciones
> (tal
>> > como me aconsejaron aquí en el grupo), lo cual me ayudó a resolver
> varias
>> > situaciones ya. Pero me topé con un aspecto inesperado. Al intentar
>> > modificar UDFs cuando ya están referidas desde alguna restriccion

Check

> de
>> > alguna (o varias) tablas, el SQL manda error de que no se puede hacer
>> > el
>> > ALTER FUNCTION.
>> >
>> > Entonces, cada vez que necesito cambiar o agregar código (así sea una
>> > línea
>> > de comentario) de una UDF ya referida, voy torpemente a cada tabla

que

> la
>> > refiere, borro la restricción, vuelvo a la UDF, hago la modificación

y

>> > luego
>> > vuelvo a cada tabla y re-escribo la llamada a la UDF (que con suerte

no

> se
>> > ha ido del portapapeles). (uffff). - jajaja...que torpeza la mía !!!.
>> > ¿ Se puede evitar hacer toooodo eso ?
>> >
>> > Y para terminar (espero no abusar de vuestra amabilidad), pregunto: ¿
> voy
>> > bien usando UDFs en las restricciones o mejor usar triggers ?? o
>> > depende
>> > el
>> > caso ? No capto aun la diferencia si bien vislumbro gran potencia en
> ambas
>> > herramientas.
>> >
>> > Gracias desde ya.
>> > Mis respetos,
>> > Marcelo
>> >
>> >
>>
>>
>
>