Reglas de empresa sobre capa de Datos.

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
>> >
>> >
>>
>>
>
>

Hola, puess, como te dije antes es un tema amplio y con muchas opciones,

en tu caso te recomendaria:

1) Tene cuidado como vas a hacer que por medio de DTS o BCP las reglas se
mantengan, opciones:

a) Los BCP y DTS van a una tabla intermedia y luego se ejecuta un

que analiza los datos y pasa a produccion
los valores buenos
b) Pones las reglas en triggers y UDF

2) Pensa que en el futuro a esa base de datos la puedan consultar de

lugares y/o sistemas.

3) Pensa en salida al exterior porque hoy no es un requisito pero no me
quiero animar a decirte que dentro de poco lo sera ;-)

4) No hay una formula en arquitectura, no me agrada mucho aquellos que
dicen: Todo en COM+ o todo en SP's creo que hay que tomar lo bueno y lo

de cada mundo y saber como usarlo :-)

Nos seguimos leyendo



Salu2
Maxi


"Marcelo Clavero" escribió en el mensaje
news:
> Gracias Maxi
>
> He respondido tus preguntas y las publico aquí solo por si tienen algo

> 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

> 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

> 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

> 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

> horario de trabajo (las bases no tienen tráfico durante la noche), y

> 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

> 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

> 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

> 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

> 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,

> 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,

>> > 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

>> > y
>> > no
>> > aparenta tan complicado.
>> >
>> > En cuanto a lo que comenta Maxi, me confundo facilmente entre lo que

>> > 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

>> > 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

>> > facil infringir la regla desde allí y perder integridad ? ¿ toy

>> > 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

>> > Marcelo
>> >
>> >
>> >
>> >
>> > "Maxi" escribió en el mensaje
>> > news:u7b#
>> >> Hola, a ver, creo que debemos separar un poco los tantos: para mi

>> >> 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

>> > 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

>> > seria
>> >> sacarlas del servidor y hacerlas en la capa de negocios, pero

> hay
>> >> que ser blanco o negro, hay muchas reglas que son muy simples de

>> >> con
>> >> TSQL con lo cual es mucho mejor hacerlas ahi.
>> >>
>> >> Yo como regla tengo: Si la regla de negocio es simple la hago en

> 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

> :-)
>> >>
>> >>
>> >> Salu2
>> >> Maxi
>> >>
>> >>
>> >> "Marcelo Clavero" escribió en el

>> >> 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

>> >> > a
>> >> > la
>> >> > capa de datos, y asegurar la integridad desde los cimientos,

>> >> > 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

>> > (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

>> >> > 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

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

> 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),

>> >> > ¿
>> > 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

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

Gracias Totales Maxi.
Has sido de mucha ayuda...ya me he hecho adicto a leer cada hilo de este
news.
Es imponente las cosas que se aprenden.

Nos leemos.-
Marcelo.

"Maxi" escribió en el mensaje
news:

Hola, puess, como te dije antes es un tema amplio y con muchas opciones,

yo

en tu caso te recomendaria:

1) Tene cuidado como vas a hacer que por medio de DTS o BCP las reglas se
mantengan, opciones:

a) Los BCP y DTS van a una tabla intermedia y luego se ejecuta un

proceso

que analiza los datos y pasa a produccion
los valores buenos
b) Pones las reglas en triggers y UDF

2) Pensa que en el futuro a esa base de datos la puedan consultar de

varios

lugares y/o sistemas.

3) Pensa en salida al exterior porque hoy no es un requisito pero no me
quiero animar a decirte que dentro de poco lo sera ;-)

4) No hay una formula en arquitectura, no me agrada mucho aquellos que
dicen: Todo en COM+ o todo en SP's creo que hay que tomar lo bueno y lo

malo

de cada mundo y saber como usarlo :-)

Nos seguimos leyendo



Salu2
Maxi


"Marcelo Clavero" escribió en el mensaje
news:
> 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
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>