Relaciones

Jiordie,

Dos cosas muy importantes que habras leido en cada mensaje son:

1 - Seguridad
2 - Usar procedimientos almacenados como interface de las reglas de negocio
residentes en la db.

Si te atienes a lo anterior, ayudaras a que la posibilidad de errores sea
menor.


AMB

"Jiordie" wrote:

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
>

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

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

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

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