Integridad referencial a través de triggers.

On Tue, 11 Jul 2006 10:52:23 +0200, " José Luis" <JLB> wrote:

gracias por contestar a mi pregunta. No acabo de ver las ventajas que me
pueden aportar el uso de la DRI en lugar de triggers. He visto por varios
sitios que en efecto recomiendan DRI en lugar de triggers, pero no he
logrado averiguar el porque, es más lento, más seguro...

Es más fácil y más estandar.

es decir, teniendo
en cuenta que la herramienta de exportación de VFP me crea la base de datos
con la integridad referencial a través de triggers no he visto que ventajas
me puede traer el cambiar la integridad a través de triggers a DRI.

Si ya lo tienes hecho déjalo estar. La ventaja es a la hora de crear
la base de datos a mano. Si ya está hecho no vas a ganar casi nada
cambiandolo.


Saludos

Hola.

Me estaba resistiendo, pero soy incapaz...

El uso de triggers es engorroso y difícil de administrar, porque están ahí,
pero no están a la vista (no aparecen en el enterprise manager como una
tabla ni se listan en el comando sp_help) y es muy fácil olvidar que los
creaste. Enmascara errores y te hace perder mucho tiempo. Luego hay triggers
que pueden hacer saltar otros triggers. Si por medio tienes transacciones,
se agrega un grado más de complejidad (errores no controlados, bloqueos,
etc).

La integridad referencial es otra cosa, es lo que garantiza que la
información de tu base de datos es coherente. Para eso están las
restricciones, tanto en la propia tabla como en relaciones entre tablas, que
evitan que metamos la pata. Es el motor y no nosotros con un trigger o con
código quien debe garantizar la coherencia de la base de datos. Al menos,
desde mi punto de vista.

Alberto López Grande (qwalgrande)


"Alfredo Novoa" escribió en el mensaje
news:

On Tue, 11 Jul 2006 10:52:23 +0200, " José Luis" <JLB> wrote:

gracias por contestar a mi pregunta. No acabo de ver las ventajas que me
pueden aportar el uso de la DRI en lugar de triggers. He visto por varios
sitios que en efecto recomiendan DRI en lugar de triggers, pero no he
logrado averiguar el porque, es más lento, más seguro...

Es más fácil y más estandar.

es decir, teniendo
en cuenta que la herramienta de exportación de VFP me crea la base de
datos
con la integridad referencial a través de triggers no he visto que
ventajas
me puede traer el cambiar la integridad a través de triggers a DRI.

Si ya lo tienes hecho déjalo estar. La ventaja es a la hora de crear
la base de datos a mano. Si ya está hecho no vas a ganar casi nada
cambiandolo.


Saludos

Estoy contigo, Alberto.

Desde mi punto de vista la simplicidad con la que DRI te garantiza la
coherencia de los datos es incomparable con los triggers. Creo que eso no es
discutible.

Ahora, si el modelo de datos ya está creado y no interesa hacer esa
modificación, es otro tema


Un saludo

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

"qwalgrande" escribió en el mensaje
news:#

Hola.

Me estaba resistiendo, pero soy incapaz...

El uso de triggers es engorroso y difícil de administrar, porque están

ahí,

pero no están a la vista (no aparecen en el enterprise manager como una
tabla ni se listan en el comando sp_help) y es muy fácil olvidar que los
creaste. Enmascara errores y te hace perder mucho tiempo. Luego hay

triggers

que pueden hacer saltar otros triggers. Si por medio tienes transacciones,
se agrega un grado más de complejidad (errores no controlados, bloqueos,
etc).

La integridad referencial es otra cosa, es lo que garantiza que la
información de tu base de datos es coherente. Para eso están las
restricciones, tanto en la propia tabla como en relaciones entre tablas,

que

evitan que metamos la pata. Es el motor y no nosotros con un trigger o con
código quien debe garantizar la coherencia de la base de datos. Al menos,
desde mi punto de vista.

Alberto López Grande (qwalgrande)


"Alfredo Novoa" escribió en el mensaje
news:
> On Tue, 11 Jul 2006 10:52:23 +0200, " José Luis" <JLB> wrote:
>
>>gracias por contestar a mi pregunta. No acabo de ver las ventajas que me
>>pueden aportar el uso de la DRI en lugar de triggers. He visto por

varios

>>sitios que en efecto recomiendan DRI en lugar de triggers, pero no he
>>logrado averiguar el porque, es más lento, más seguro...
>
> Es más fácil y más estandar.
>
>> es decir, teniendo
>>en cuenta que la herramienta de exportación de VFP me crea la base de
>>datos
>>con la integridad referencial a través de triggers no he visto que
>>ventajas
>>me puede traer el cambiar la integridad a través de triggers a DRI.
>
> Si ya lo tienes hecho déjalo estar. La ventaja es a la hora de crear
> la base de datos a mano. Si ya está hecho no vas a ganar casi nada
> cambiandolo.
>
>
> Saludos

On Tue, 11 Jul 2006 19:13:35 +0200, in microsoft.public.es.sqlserver
you wrote:

El uso de triggers es engorroso y difícil de administrar, porque están ahí,
pero no están a la vista (no aparecen en el enterprise manager como una
tabla ni se listan en el comando sp_help) y es muy fácil olvidar que los
creaste. Enmascara errores y te hace perder mucho tiempo. Luego hay triggers
que pueden hacer saltar otros triggers. Si por medio tienes transacciones,
se agrega un grado más de complejidad (errores no controlados, bloqueos,
etc).

La integridad referencial es otra cosa, es lo que garantiza que la
información de tu base de datos es coherente.

Es una de las muchas cosas que lo garantizan y es independiente de
como se implemente (declarativo o procedimental).

Estoy de acuerdo en que los "triggers" y los otros procedimientos
almacenados deben de ser siempre un último recurso para lo que no se
pueda hacer de forma declarativa.

evitan que metamos la pata. Es el motor y no nosotros con un trigger o con
código quien debe garantizar la coherencia de la base de datos.

Es el SGBD el que debe hacerlo y los "triggers" los ejecuta el SGBD y
no nosotros.


Saludos

Alfredo, me parece bien que hagas comentarios porque creo tienes el
criterio suficiente para hacerlo. He leído muchos post tuyos y, aunque casi
siempre son polémicos, la verdad es que en muchas ocasiones es un punto de
vista muy interesante.

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
Alberto se refería a que el código de los triggers lo tienen que hacer los
programadores, lo cual es propenso a errores. Por lo menos mucho más
propenso a errores que DRI


Un saludo

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

"Alfredo Novoa" escribió en el mensaje
news:

On Tue, 11 Jul 2006 19:13:35 +0200, in microsoft.public.es.sqlserver
you wrote:

>El uso de triggers es engorroso y difícil de administrar, porque están

ahí,

>pero no están a la vista (no aparecen en el enterprise manager como una
>tabla ni se listan en el comando sp_help) y es muy fácil olvidar que los
>creaste. Enmascara errores y te hace perder mucho tiempo. Luego hay

triggers

>que pueden hacer saltar otros triggers. Si por medio tienes

transacciones,

>se agrega un grado más de complejidad (errores no controlados, bloqueos,
>etc).
>
>La integridad referencial es otra cosa, es lo que garantiza que la
>información de tu base de datos es coherente.

Es una de las muchas cosas que lo garantizan y es independiente de
como se implemente (declarativo o procedimental).

Estoy de acuerdo en que los "triggers" y los otros procedimientos
almacenados deben de ser siempre un último recurso para lo que no se
pueda hacer de forma declarativa.

>evitan que metamos la pata. Es el motor y no nosotros con un trigger o

con

>código quien debe garantizar la coherencia de la base de datos.

Es el SGBD el que debe hacerlo y los "triggers" los ejecuta el SGBD y
no nosotros.


Saludos