Relaciones

A ver, es cierto lo que indicas pero cuando trabajas como te digo donde por
ej un DBa hace tareas administrativasd de migracionde un ERP y labura sobre
la bdd o cosas por el estilo, por mas que tengas una buena politica de
backup y puedas restaurar la informacion podes tener problemas de
disponibilidad, por eso trato de evitar cosas de este tipo, si una persona
que tiene permisos porque realmente lo necesita comete un error de estos
entonces podemos tener serios problemas, de esta manera lo unico que logro
es en disminuir esta posibilidad y si sin querer da un Delete y no hay
cascada entonces lo alertara el mismo motor.

Son solo formas y depende mucho los escenarios, si es un escenario donde
solo la aplicacion mete mano sobre la bdd coincido contigo en que la cosa no
cambia nada y seria mejor usar borrado en cascada, pero en scenarios donde
no solo la aplicacion mete mano ahi hay que tener algunos recaudos mas :(


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en el
mensaje news:

Maxi,

Estoy de acuerdo que un error puede llevar a borrar data de manera no
intencionada, pero eso lo podemos disminuir con procedimientos
almacenados,
seguridad y una buena estrategia de "backup - restore".

Como dijo Salvador, tambien podemos cometer un error al ejecutar el
procedimiento que no era, no crees?

Saludos,

AMB

"Maxi" wrote:

Ale, es una cuestion de riesgos como te dijo bien Salvador y es
justamente a
donde apuntaba yo. No es que este mal usar cascada ni mucho menos, es que
un
mini error puede ser mortal, la otra manera a mi me da mucho mas
seguridad y
como bien dijo Carlos, el Sp de Delete lo debes hacer entonces lo pongo
ahi


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en el
mensaje news:
> Maxi,
>
>> Imaginemos un caso en el cual tenemos un maestro de articulos y muchos
>> pedidos que hacen referencia, si dejo la eliminacion en cascada un
>> delete
>> sobre el maestro me borra todo quizas y puedo tener muchos problemas
>
> No tengo como resaltar texto, pero tu ya lo has dicho, "si dejo". Si
> usamos
> un sp para borrar desde el maestro (y no veo porque no usarlo aunque el
> borrado y actualizacion en casacda esten activos), se puede chequear
> existencia antes de eliminar una fila en la parte "padre" de una
> relacion.
>
> No se por que consideras sinonimos "borrado en cascada" y "borrar
> manualmente desde la tabla"?.
>
>
> AMB
>
> "Maxi [MVP]" wrote:
>
>> Hola, no hay nada encontra de ello, solo que en mi caso me gusta
>> controlar a
>> mi que cosas borro y como las borro, no es solo cuestion de borrar en
>> muchos
>> casos, quizas necesites una logica de negocios que podes poner bien
>> dentro
>> de un Sp's por ej y controlar.
>>
>> Imaginemos un caso en el cual tenemos un maestro de articulos y muchos
>> pedidos que hacen referencia, si dejo la eliminacion en cascada un
>> delete
>> sobre el maestro me borra todo quizas y puedo tener muchos problemas,
>> si
>> lo
>> pongo en un Sp's puedo controlar que cosas borrar y como, y no solo
>> eso
>> si
>> hay un error un simple delete dara error porque hay relaciones que
>> estan
>> vinculadas, de la otra manera borra no solo el articulo sino todo lo
>> que
>> esta abajo :(
>>
>>
>> Salu2
>> -
>> [MVP] SQL Server
>> Orador para Culminis Latam
>> www.sqlgurus.org
>>
>> MSN:
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Jiordie,
>> >
>> > No hay nada de malo en eso, a la final si no dejas que SQL Server lo
>> > haga,
>> > tendras que hacerlo tu proceduralmente. No se pierde ningun control
>> > con
>> > esto,
>> > el control lo perdemos cuando le damos permiso a un usuario de
>> > borrar
>> > directamente en la tabla y no atraves de un procedimiento.
>> >
>> > Mas que questiones de gusto, le pediria a los demas miembros del
>> > grupo
>> > que
>> > postearan situaciones o casos que esten en contra del usa de las
>> > mismas
>> > (opciones de borrado y actualizacion en cascada).
>> >
>> >
>> > AMB
>> >
>> >
>> > "Jiordie" wrote:
>> >
>> >> Hola a todos!
>> >>
>> >> Alguien me puede orientar sobre esto?, qué tan bueno o malo es
>> >> colocar
>> >> en
>> >> las relaciones actualización y borrado en cascada?. si tienen un
>> >> link
>> >> donde
>> >> me pueda instruir acerca del tema les agradecería.
>> >>
>> >> Desde ya muchas gracias
>> >>
>> >>
>> >>
>>
>>
>>

Maxi,

Estoy de acuerdo con lo que planteas. Que pasaria si en vez del "delete", el
dba ejecuta el sp pero pasa los parametros que no eran?. La propensidad a
cometer un error siempre estara latente.

AMB

"Maxi" wrote:

Ale, hay una cosa, vos estas pensando solo en permisos de usuarios finales,
hay muchas empresas que tienen sus propios DBA que hacen tareas de
mantenimiento a sistemas ERP por ej, y muchas veces se necesitan borrar
cosas, por lo general estos DBA usan Delete derecho nomas, y por mas que
digas que deberian tener la experiencia y todo lo demas, evitar errores de
este tipo te pueden salvar la vida. Conozco varios casos que ha pasado esto


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en el
mensaje news:
> Salvador,
>
> Acerca de los errores, eso siempre estara latente, sin importar por cual
> de
> las opciones optemos. Solo quiero recalcar la importancia de una buena
> estrategia de "backup / restore" para poder contrarrestar esta posibilidad
> siempre existente de cometer errores. Tambien puntualizar cuan importante
> es
> la seguridad de db, por que darle permiso a usuario para borrar
> directamente
> de la tabla usando ad-hoc queries?. El mismo chequeo de existencia se
> puede
> hacer independientemente de cual opcion escojamos, pero estoy de acuerdo
> que
> poniendo esta logica dentro de un sp es lo mas recomendado.
>
> Yo por mi parte trato de usar lo mas que pueda de una forma declarativa,
> pues las implementaciones procedurales son mas propensa a errores.
>
> Saludos,
>
> Alejandro Mesa
>
> "Salvador Ramos" wrote:
>
>> Hola Alejandro,
>>
>> Creo que todos estamos de acuerdo en que dándole un buen uso, no hay
>> ventajas ni inconvenientes justificables, más bien es cuestión de gusto.
>>
>> Yo la única ventaja que le veo a no usarlo, es que con las
>> actualizaciones y
>> borrados en cascada, un fallo puede tener consecuencias más graves.
>> Considerando por ejemplo como fallo, que se le dé un permiso inapropiado
>> a
>> algún user, que alguien lance un delete por error, o cualquier otro.
>> Aunque
>> también me puedes decir que alguien puede lanzar por error ese sp que
>> hace
>> el borrado en cascada desarrollado por nosotros, pero lo veo más
>> improbable.
>>
>> Un saludo
>> Salvador Ramos
>> Murcia - España
>>
>> [Microsoft MVP SQL Server]
>> www.helpdna.net (información sobre SQL Server y .NET)
>>
>>
>> "Alejandro Mesa" escribió en el
>> mensaje news:
>> > Jiordie,
>> >
>> > No hay nada de malo en eso, a la final si no dejas que SQL Server lo
>> > haga,
>> > tendras que hacerlo tu proceduralmente. No se pierde ningun control con
>> > esto,
>> > el control lo perdemos cuando le damos permiso a un usuario de borrar
>> > directamente en la tabla y no atraves de un procedimiento.
>> >
>> > Mas que questiones de gusto, le pediria a los demas miembros del grupo
>> > que
>> > postearan situaciones o casos que esten en contra del usa de las mismas
>> > (opciones de borrado y actualizacion en cascada).
>> >
>> >
>> > AMB
>> >
>> >
>> > "Jiordie" wrote:
>> >
>> >> Hola a todos!
>> >>
>> >> Alguien me puede orientar sobre esto?, qué tan bueno o malo es colocar
>> >> en
>> >> las relaciones actualización y borrado en cascada?. si tienen un link
>> >> donde
>> >> me pueda instruir acerca del tema les agradecería.
>> >>
>> >> Desde ya muchas gracias
>> >>
>> >>
>> >>
>>
>>
>>

Si Ale claro que es latente, pero estamos hablando de cosas distintas creo,
el DBA por lo general en una tarea de mantenimiento puede o no usar el SP,
si no usa el SP y no tiene cascada le marcaria un error, si usa el SP
borraria todo tambien. Que digo, si siempre vas a usar SP y nunca una
funcion Delete entonces esta bien poner la cascada porque el riesgo es el
mismo, ahora si tambien puede existir que alguien (por ej un DBa en estos
casos q te comente) pueda ejecutar un Delete entonces a mi me gusta ser mas
precavido y tratar de evitar problemas donde diga huuuu me borro todo porque
no me di cuenta q tenia cascada. Pero te vuelvo a decir, yo no estoy
encontra de la cascada solo que me gusta tener a mi el control y evitar los
errores de este tipo, he sufrido en varias empresas esto y el cliente lo que
te pide es tratar de disminuir los riesgos, entonces :(

Ahora hay una cosa, en sql2005 tenemos dos DRI nuevos que podrias ayudar a
evitar errores, porque un delete podria hacer que se pongan en null los
datos y ya y por lo menos identificar que paso eso y no perder toda la
data.

Un abrazo com siempre


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en el
mensaje news:

Maxi,

Estoy de acuerdo con lo que planteas. Que pasaria si en vez del "delete",
el
dba ejecuta el sp pero pasa los parametros que no eran?. La propensidad a
cometer un error siempre estara latente.

AMB

"Maxi" wrote:

Ale, hay una cosa, vos estas pensando solo en permisos de usuarios
finales,
hay muchas empresas que tienen sus propios DBA que hacen tareas de
mantenimiento a sistemas ERP por ej, y muchas veces se necesitan borrar
cosas, por lo general estos DBA usan Delete derecho nomas, y por mas que
digas que deberian tener la experiencia y todo lo demas, evitar errores
de
este tipo te pueden salvar la vida. Conozco varios casos que ha pasado
esto


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en el
mensaje news:
> Salvador,
>
> Acerca de los errores, eso siempre estara latente, sin importar por
> cual
> de
> las opciones optemos. Solo quiero recalcar la importancia de una buena
> estrategia de "backup / restore" para poder contrarrestar esta
> posibilidad
> siempre existente de cometer errores. Tambien puntualizar cuan
> importante
> es
> la seguridad de db, por que darle permiso a usuario para borrar
> directamente
> de la tabla usando ad-hoc queries?. El mismo chequeo de existencia se
> puede
> hacer independientemente de cual opcion escojamos, pero estoy de
> acuerdo
> que
> poniendo esta logica dentro de un sp es lo mas recomendado.
>
> Yo por mi parte trato de usar lo mas que pueda de una forma
> declarativa,
> pues las implementaciones procedurales son mas propensa a errores.
>
> Saludos,
>
> Alejandro Mesa
>
> "Salvador Ramos" wrote:
>
>> Hola Alejandro,
>>
>> Creo que todos estamos de acuerdo en que dándole un buen uso, no hay
>> ventajas ni inconvenientes justificables, más bien es cuestión de
>> gusto.
>>
>> Yo la única ventaja que le veo a no usarlo, es que con las
>> actualizaciones y
>> borrados en cascada, un fallo puede tener consecuencias más graves.
>> Considerando por ejemplo como fallo, que se le dé un permiso
>> inapropiado
>> a
>> algún user, que alguien lance un delete por error, o cualquier otro.
>> Aunque
>> también me puedes decir que alguien puede lanzar por error ese sp que
>> hace
>> el borrado en cascada desarrollado por nosotros, pero lo veo más
>> improbable.
>>
>> Un saludo
>> Salvador Ramos
>> Murcia - España
>>
>> [Microsoft MVP SQL Server]
>> www.helpdna.net (información sobre SQL Server y .NET)
>>
>>
>> "Alejandro Mesa" escribió en
>> el
>> mensaje news:
>> > Jiordie,
>> >
>> > No hay nada de malo en eso, a la final si no dejas que SQL Server lo
>> > haga,
>> > tendras que hacerlo tu proceduralmente. No se pierde ningun control
>> > con
>> > esto,
>> > el control lo perdemos cuando le damos permiso a un usuario de
>> > borrar
>> > directamente en la tabla y no atraves de un procedimiento.
>> >
>> > Mas que questiones de gusto, le pediria a los demas miembros del
>> > grupo
>> > que
>> > postearan situaciones o casos que esten en contra del usa de las
>> > mismas
>> > (opciones de borrado y actualizacion en cascada).
>> >
>> >
>> > AMB
>> >
>> >
>> > "Jiordie" wrote:
>> >
>> >> Hola a todos!
>> >>
>> >> Alguien me puede orientar sobre esto?, qué tan bueno o malo es
>> >> colocar
>> >> en
>> >> las relaciones actualización y borrado en cascada?. si tienen un
>> >> link
>> >> donde
>> >> me pueda instruir acerca del tema les agradecería.
>> >>
>> >> Desde ya muchas gracias
>> >>
>> >>
>> >>
>>
>>
>>

Yo, por avivar la polémica, estoy de acuerdo con Alejandro, lo que se puede
hacer de forma declarativa hagámoslo de forma declarativa.

Sin embargo, y aunque soy murciano y no gallego, lo cierto es que en mi
opinión usar o no On Delete casdade u cualquiera otra opción como SET NULL o
la que sea depende de la entidad que se esté borrando más que la tecnología,
así pues si pondría on delete cascade para que borrado un pedido se borren
sus líneas, y los datos asociados a la factura y no lo usaría para por
ejemplo que borrado una forma de pago se borren todas las facturas de esa
forma de pago. Creo que con el ejemplo se vé cual es la razón que subyace
detrás


Miguel Egea
Visita mi web http://www.portalsql.com
SQL Server MVP, Mentor
Solid Quality Learning
http://www.SolidQualityLearning.com
"Solid Quality Learning is the trusted global provider of advanced education
and solutions for the entire Microsoft database platform"



"Maxi" wrote in message
news:OyBRRw$

Si Ale claro que es latente, pero estamos hablando de cosas distintas
creo, el DBA por lo general en una tarea de mantenimiento puede o no usar
el SP, si no usa el SP y no tiene cascada le marcaria un error, si usa el
SP borraria todo tambien. Que digo, si siempre vas a usar SP y nunca una
funcion Delete entonces esta bien poner la cascada porque el riesgo es el
mismo, ahora si tambien puede existir que alguien (por ej un DBa en estos
casos q te comente) pueda ejecutar un Delete entonces a mi me gusta ser
mas precavido y tratar de evitar problemas donde diga huuuu me borro todo
porque no me di cuenta q tenia cascada. Pero te vuelvo a decir, yo no
estoy encontra de la cascada solo que me gusta tener a mi el control y
evitar los errores de este tipo, he sufrido en varias empresas esto y el
cliente lo que te pide es tratar de disminuir los riesgos, entonces :(

Ahora hay una cosa, en sql2005 tenemos dos DRI nuevos que podrias ayudar a
evitar errores, porque un delete podria hacer que se pongan en null los
datos y ya y por lo menos identificar que paso eso y no perder toda la
data.

Un abrazo com siempre


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en el
mensaje news:

Maxi,

Estoy de acuerdo con lo que planteas. Que pasaria si en vez del "delete",
el
dba ejecuta el sp pero pasa los parametros que no eran?. La propensidad a
cometer un error siempre estara latente.

AMB

"Maxi" wrote:

Ale, hay una cosa, vos estas pensando solo en permisos de usuarios
finales,
hay muchas empresas que tienen sus propios DBA que hacen tareas de
mantenimiento a sistemas ERP por ej, y muchas veces se necesitan borrar
cosas, por lo general estos DBA usan Delete derecho nomas, y por mas que
digas que deberian tener la experiencia y todo lo demas, evitar errores
de
este tipo te pueden salvar la vida. Conozco varios casos que ha pasado
esto


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en
el
mensaje news:
> Salvador,
>
> Acerca de los errores, eso siempre estara latente, sin importar por
> cual
> de
> las opciones optemos. Solo quiero recalcar la importancia de una buena
> estrategia de "backup / restore" para poder contrarrestar esta
> posibilidad
> siempre existente de cometer errores. Tambien puntualizar cuan
> importante
> es
> la seguridad de db, por que darle permiso a usuario para borrar
> directamente
> de la tabla usando ad-hoc queries?. El mismo chequeo de existencia se
> puede
> hacer independientemente de cual opcion escojamos, pero estoy de
> acuerdo
> que
> poniendo esta logica dentro de un sp es lo mas recomendado.
>
> Yo por mi parte trato de usar lo mas que pueda de una forma
> declarativa,
> pues las implementaciones procedurales son mas propensa a errores.
>
> Saludos,
>
> Alejandro Mesa
>
> "Salvador Ramos" wrote:
>
>> Hola Alejandro,
>>
>> Creo que todos estamos de acuerdo en que dándole un buen uso, no hay
>> ventajas ni inconvenientes justificables, más bien es cuestión de
>> gusto.
>>
>> Yo la única ventaja que le veo a no usarlo, es que con las
>> actualizaciones y
>> borrados en cascada, un fallo puede tener consecuencias más graves.
>> Considerando por ejemplo como fallo, que se le dé un permiso
>> inapropiado
>> a
>> algún user, que alguien lance un delete por error, o cualquier otro.
>> Aunque
>> también me puedes decir que alguien puede lanzar por error ese sp que
>> hace
>> el borrado en cascada desarrollado por nosotros, pero lo veo más
>> improbable.
>>
>> Un saludo
>> Salvador Ramos
>> Murcia - España
>>
>> [Microsoft MVP SQL Server]
>> www.helpdna.net (información sobre SQL Server y .NET)
>>
>>
>> "Alejandro Mesa" escribió
>> en el
>> mensaje news:
>> > Jiordie,
>> >
>> > No hay nada de malo en eso, a la final si no dejas que SQL Server
>> > lo
>> > haga,
>> > tendras que hacerlo tu proceduralmente. No se pierde ningun control
>> > con
>> > esto,
>> > el control lo perdemos cuando le damos permiso a un usuario de
>> > borrar
>> > directamente en la tabla y no atraves de un procedimiento.
>> >
>> > Mas que questiones de gusto, le pediria a los demas miembros del
>> > grupo
>> > que
>> > postearan situaciones o casos que esten en contra del usa de las
>> > mismas
>> > (opciones de borrado y actualizacion en cascada).
>> >
>> >
>> > AMB
>> >
>> >
>> > "Jiordie" wrote:
>> >
>> >> Hola a todos!
>> >>
>> >> Alguien me puede orientar sobre esto?, qué tan bueno o malo es
>> >> colocar
>> >> en
>> >> las relaciones actualización y borrado en cascada?. si tienen un
>> >> link
>> >> donde
>> >> me pueda instruir acerca del tema les agradecería.
>> >>
>> >> Desde ya muchas gracias
>> >>
>> >>
>> >>
>>
>>
>>

Bueno coincidimos :-)


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Miguel Egea" escribió en el mensaje
news:

Yo, por avivar la polémica, estoy de acuerdo con Alejandro, lo que se
puede hacer de forma declarativa hagámoslo de forma declarativa.

Sin embargo, y aunque soy murciano y no gallego, lo cierto es que en mi
opinión usar o no On Delete casdade u cualquiera otra opción como SET NULL
o la que sea depende de la entidad que se esté borrando más que la
tecnología, así pues si pondría on delete cascade para que borrado un
pedido se borren sus líneas, y los datos asociados a la factura y no lo
usaría para por ejemplo que borrado una forma de pago se borren todas las
facturas de esa forma de pago. Creo que con el ejemplo se vé cual es la
razón que subyace detrás


Miguel Egea
Visita mi web http://www.portalsql.com
SQL Server MVP, Mentor
Solid Quality Learning
http://www.SolidQualityLearning.com
"Solid Quality Learning is the trusted global provider of advanced
education and solutions for the entire Microsoft database platform"



"Maxi" wrote in message
news:OyBRRw$

Si Ale claro que es latente, pero estamos hablando de cosas distintas
creo, el DBA por lo general en una tarea de mantenimiento puede o no usar
el SP, si no usa el SP y no tiene cascada le marcaria un error, si usa el
SP borraria todo tambien. Que digo, si siempre vas a usar SP y nunca una
funcion Delete entonces esta bien poner la cascada porque el riesgo es el
mismo, ahora si tambien puede existir que alguien (por ej un DBa en estos
casos q te comente) pueda ejecutar un Delete entonces a mi me gusta ser
mas precavido y tratar de evitar problemas donde diga huuuu me borro todo
porque no me di cuenta q tenia cascada. Pero te vuelvo a decir, yo no
estoy encontra de la cascada solo que me gusta tener a mi el control y
evitar los errores de este tipo, he sufrido en varias empresas esto y el
cliente lo que te pide es tratar de disminuir los riesgos, entonces
:(

Ahora hay una cosa, en sql2005 tenemos dos DRI nuevos que podrias ayudar
a evitar errores, porque un delete podria hacer que se pongan en null los
datos y ya y por lo menos identificar que paso eso y no perder toda la
data.

Un abrazo com siempre


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en el
mensaje news:

Maxi,

Estoy de acuerdo con lo que planteas. Que pasaria si en vez del
"delete", el
dba ejecuta el sp pero pasa los parametros que no eran?. La propensidad
a
cometer un error siempre estara latente.

AMB

"Maxi" wrote:

Ale, hay una cosa, vos estas pensando solo en permisos de usuarios
finales,
hay muchas empresas que tienen sus propios DBA que hacen tareas de
mantenimiento a sistemas ERP por ej, y muchas veces se necesitan borrar
cosas, por lo general estos DBA usan Delete derecho nomas, y por mas
que
digas que deberian tener la experiencia y todo lo demas, evitar errores
de
este tipo te pueden salvar la vida. Conozco varios casos que ha pasado
esto


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Alejandro Mesa" escribió en
el
mensaje news:
> Salvador,
>
> Acerca de los errores, eso siempre estara latente, sin importar por
> cual
> de
> las opciones optemos. Solo quiero recalcar la importancia de una
> buena
> estrategia de "backup / restore" para poder contrarrestar esta
> posibilidad
> siempre existente de cometer errores. Tambien puntualizar cuan
> importante
> es
> la seguridad de db, por que darle permiso a usuario para borrar
> directamente
> de la tabla usando ad-hoc queries?. El mismo chequeo de existencia se
> puede
> hacer independientemente de cual opcion escojamos, pero estoy de
> acuerdo
> que
> poniendo esta logica dentro de un sp es lo mas recomendado.
>
> Yo por mi parte trato de usar lo mas que pueda de una forma
> declarativa,
> pues las implementaciones procedurales son mas propensa a errores.
>
> Saludos,
>
> Alejandro Mesa
>
> "Salvador Ramos" wrote:
>
>> Hola Alejandro,
>>
>> Creo que todos estamos de acuerdo en que dándole un buen uso, no hay
>> ventajas ni inconvenientes justificables, más bien es cuestión de
>> gusto.
>>
>> Yo la única ventaja que le veo a no usarlo, es que con las
>> actualizaciones y
>> borrados en cascada, un fallo puede tener consecuencias más graves.
>> Considerando por ejemplo como fallo, que se le dé un permiso
>> inapropiado
>> a
>> algún user, que alguien lance un delete por error, o cualquier otro.
>> Aunque
>> también me puedes decir que alguien puede lanzar por error ese sp
>> que
>> hace
>> el borrado en cascada desarrollado por nosotros, pero lo veo más
>> improbable.
>>
>> Un saludo
>> Salvador Ramos
>> Murcia - España
>>
>> [Microsoft MVP SQL Server]
>> www.helpdna.net (información sobre SQL Server y .NET)
>>
>>
>> "Alejandro Mesa" escribió
>> en el
>> mensaje news:
>> > Jiordie,
>> >
>> > No hay nada de malo en eso, a la final si no dejas que SQL Server
>> > lo
>> > haga,
>> > tendras que hacerlo tu proceduralmente. No se pierde ningun
>> > control con
>> > esto,
>> > el control lo perdemos cuando le damos permiso a un usuario de
>> > borrar
>> > directamente en la tabla y no atraves de un procedimiento.
>> >
>> > Mas que questiones de gusto, le pediria a los demas miembros del
>> > grupo
>> > que
>> > postearan situaciones o casos que esten en contra del usa de las
>> > mismas
>> > (opciones de borrado y actualizacion en cascada).
>> >
>> >
>> > AMB
>> >
>> >
>> > "Jiordie" wrote:
>> >
>> >> Hola a todos!
>> >>
>> >> Alguien me puede orientar sobre esto?, qué tan bueno o malo es
>> >> colocar
>> >> en
>> >> las relaciones actualización y borrado en cascada?. si tienen un
>> >> link
>> >> donde
>> >> me pueda instruir acerca del tema les agradecería.
>> >>
>> >> Desde ya muchas gracias
>> >>
>> >>
>> >>
>>
>>
>>