Integridad referencial a través de triggers.

On Wed, 12 Jul 2006 13:01:51 +0200, "Carlos Sacristán"
<csacristanARROBAmvpsPUNTOorg> wrote:

Pero el último comentario que haces acerca de que es el gestor de la
base de datos el que ejecuta los triggers y no nosotros me parece que es ser
ya un punto excesivamente puntilloso. Lo que comentas está claro, pero

A mi no me parece puntilloso. Lo que escribió Alberto sugiere que los
triggers no son un recurso propio de los SGBD, comparándolos con el
código de la aplicación. Los triggers son (algunas veces) un recurso
legítimo para mantener la integridad de la base de datos y el código
de la aplicación no lo es.

Alberto se refería a que el código de los triggers lo tienen que hacer los
programadores,

Más bien los DBA, pero el código declarativo también, aunque sea mucho
más sencillo y fiable.

lo cual es propenso a errores. Por lo menos mucho más
propenso a errores que DRI

Completamente de acuerdo.

Saludos
Alfredo

Hola.

Los triggers, así como los cursores, las vistas, las tablas temporales, las
claves foráneas con borrados o actualización en cascada, y ahora el CLR, son
en todos los casos recursos del gestor de bases de datos. Otra cosa es que
sea buena idea utilizarlos. En muchas ocasiones los usamos por comodidad, en
otras porque no queda más remedio o porque pensamos que es la mejor forma de
resolver un punto concreto.

Yo, en este caso, no estoy de acuerdo contigo, Alfredo. Tienes un sistema de
información basado en otro gestor y decides migrarlo a SQL Server. Como el
proceso de migración no genera constraints de integridad, si no que viene
con un conjunto de triggers, prefieres conservarlo. Decisión comprensible si
tienes un problema de tiempo o de recursos, pero salvo por eso, no creo que
sea la mejor forma de resolver el problema. Sinceramente, si partieras de
cero y tuvieras que diseñar ese modelo, ¿gestionarías la integridad
referencial con triggers? Seguro que no.

Alberto López Grande (qwalgrande)


"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 12 Jul 2006 13:01:51 +0200, "Carlos Sacristán"
<csacristanARROBAmvpsPUNTOorg> wrote:

Pero el último comentario que haces acerca de que es el gestor de la
base de datos el que ejecuta los triggers y no nosotros me parece que es
ser
ya un punto excesivamente puntilloso. Lo que comentas está claro, pero

A mi no me parece puntilloso. Lo que escribió Alberto sugiere que los
triggers no son un recurso propio de los SGBD, comparándolos con el
código de la aplicación. Los triggers son (algunas veces) un recurso
legítimo para mantener la integridad de la base de datos y el código
de la aplicación no lo es.

Alberto se refería a que el código de los triggers lo tienen que hacer los
programadores,

Más bien los DBA, pero el código declarativo también, aunque sea mucho
más sencillo y fiable.

lo cual es propenso a errores. Por lo menos mucho más
propenso a errores que DRI

Completamente de acuerdo.

Saludos
Alfredo

Hola a todos,

muchas gracias a todos por aportar vuestra opinión sobre el hilo que he
expuesto. Viendo lo dicho creo que lo mejor, y más que voy empezando, es
tirar a través de DRI aunque esto me suponga más trabajo. Ya que por lo
leído parece que es la mejor opción.

Muchas gracias.

Un saludo,
José Luis.

"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 12 Jul 2006 13:01:51 +0200, "Carlos Sacristán"
<csacristanARROBAmvpsPUNTOorg> wrote:

Pero el último comentario que haces acerca de que es el gestor de la
base de datos el que ejecuta los triggers y no nosotros me parece que es
ser
ya un punto excesivamente puntilloso. Lo que comentas está claro, pero

A mi no me parece puntilloso. Lo que escribió Alberto sugiere que los
triggers no son un recurso propio de los SGBD, comparándolos con el
código de la aplicación. Los triggers son (algunas veces) un recurso
legítimo para mantener la integridad de la base de datos y el código
de la aplicación no lo es.

Alberto se refería a que el código de los triggers lo tienen que hacer los
programadores,

Más bien los DBA, pero el código declarativo también, aunque sea mucho
más sencillo y fiable.

lo cual es propenso a errores. Por lo menos mucho más
propenso a errores que DRI

Completamente de acuerdo.

Saludos
Alfredo

Coincido contigo


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org
Speaker INETA
Speaker Culminis


"qwalgrande" escribió en el mensaje
news:

Hola.

Los triggers, así como los cursores, las vistas, las tablas temporales,
las claves foráneas con borrados o actualización en cascada, y ahora el
CLR, son en todos los casos recursos del gestor de bases de datos. Otra
cosa es que sea buena idea utilizarlos. En muchas ocasiones los usamos por
comodidad, en otras porque no queda más remedio o porque pensamos que es
la mejor forma de resolver un punto concreto.

Yo, en este caso, no estoy de acuerdo contigo, Alfredo. Tienes un sistema
de información basado en otro gestor y decides migrarlo a SQL Server. Como
el proceso de migración no genera constraints de integridad, si no que
viene con un conjunto de triggers, prefieres conservarlo. Decisión
comprensible si tienes un problema de tiempo o de recursos, pero salvo por
eso, no creo que sea la mejor forma de resolver el problema. Sinceramente,
si partieras de cero y tuvieras que diseñar ese modelo, ¿gestionarías la
integridad referencial con triggers? Seguro que no.

Alberto López Grande (qwalgrande)


"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 12 Jul 2006 13:01:51 +0200, "Carlos Sacristán"
<csacristanARROBAmvpsPUNTOorg> wrote:

Pero el último comentario que haces acerca de que es el gestor de la
base de datos el que ejecuta los triggers y no nosotros me parece que es
ser
ya un punto excesivamente puntilloso. Lo que comentas está claro, pero

A mi no me parece puntilloso. Lo que escribió Alberto sugiere que los
triggers no son un recurso propio de los SGBD, comparándolos con el
código de la aplicación. Los triggers son (algunas veces) un recurso
legítimo para mantener la integridad de la base de datos y el código
de la aplicación no lo es.

Alberto se refería a que el código de los triggers lo tienen que hacer
los
programadores,

Más bien los DBA, pero el código declarativo también, aunque sea mucho
más sencillo y fiable.

lo cual es propenso a errores. Por lo menos mucho más
propenso a errores que DRI

Completamente de acuerdo.

Saludos
Alfredo