Relaciones

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

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

Muchas gracias todos por sus opiniones, en fin llego a la conclusión
que es es cuestión de diseño, habrán relaciones en las cuales se pueda
colocar actualizacion en cascada y otras en las cuales no, lo mismo para
eliminación, lo que si es que hay que estudiar bien la situación con el fin
de llegar al mejor diseño y rendimiento posible.

esta es mi humilde opinion... luego de leer sus opiniones que me ayudaron
bastante.


"Jiordie" escribió en el
mensaje news:

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 estoy de acuerdo con la opinión de Salva: prefiero implementar ese
borrado/actualización en cascada desde un procedimiento almacenado, que es
al fin y al cabo a donde voy a llamar para realizar la modificación.

Creo que es el mismo caso por el cual no me gustan los triggers: tienes
la lógica desperdigada por varios sitios.


Un saludo

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

"Salvador Ramos" escribió en el
mensaje news:#rf6#Q#

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

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