Tablas deleted y Inserted.

Hola Alfredo:

Alfredo Novoa ha escrito:

Hola Juan Diego,

El Tue, 16 Dec 2008 22:09:34 +0100, Juan Diego Bueno escribi�:

>> Lo que se me ocurre es que crees un campo identity que no se use para nada
>> m�s, y as� ya tienes una forma de identificar las filas.
>>
> �Recuerdas aqu�l post en el que yo hablaba de no modificar nunca la clave
> primaria y t� no ve�as el por qu�?

Sigo sin verlo. Estamos justamente hablando de como podemos hacer para
modificar la clave primaria :-)


> Pues �sta es una de esas situaciones que a mi se me ha dado m�s de una vez
> (por ejemplo, un cambio de NIF de un registro de personal) y que me
> empujaron en su momento a usar ids jugando con otros campos pero inmutables,
> o ids num�ricos.

A mi tambi�n me ha pasado alguna vez y es otra vez por culpa de los
defectos de SQL Server. Por ejemplo con Firebird esto no pasa.

Sí, esto viene a cuento porque yo en aquellos post, decía que generaba
una clave primaria a partir de otra única. Por ejemplo, no usaba el
NIF como tal, sino una generada a partir del NIF y usando una
numeración aleatoria de forma que si alguna vez ese NIF se modificaba,
se mantuviera la clave principal y si se volvía a introducir el primer
NIF, se generara una clave principal a partir de él que no coincidiera
con la anterior (no sé si se me ha entendido, es un pelín retorcido)

Pero cuando pasa le a�ades a la tabla un campo identity que solo sirve para
usar en los triggers y luego te creas una vista que no contenga la clave
artificial y listo.

El problema solo ocurre cuando tienes claves externas con actualizaciones
en cascada que hacen referencia a una tabla que tienes que actualizar con
triggers.

Esto es un poco lo mismo que lo que yo digo, pero lo mío es una
solución casera. Ya sé que no es lo mismo, pero en un caso genero un
id que sirve de clave principal de forma artificial y es inmutable
(dejando el NIF como UNIQUE), y en tu caso, se usa un autonumérico
(que no es clave) para solventar esa situación. Yo lo que trato es de
evitar la situación antes de que surja.

De todas maneras, entiendo lo que dices y lo acepto. Sólo quería
exponer cómo afronté yo en su momento esta situación.


Un saludo

Hola Juan Diego,

El Wed, 17 Dec 2008 01:03:18 -0800 (PST), Juan Diego Bueno escribió:

Sí, esto viene a cuento porque yo en aquellos post, decía que generaba
una clave primaria a partir de otra única. Por ejemplo, no usaba el
NIF como tal, sino una generada a partir del NIF y usando una
numeración aleatoria de forma que si alguna vez ese NIF se modificaba,
se mantuviera la clave principal y si se volvía a introducir el primer
NIF, se generara una clave principal a partir de él que no coincidiera
con la anterior (no sé si se me ha entendido, es un pelín retorcido)

Pues sí que es retorcido. ¿Y por que no usar un entero sin más?

El problema solo ocurre cuando tienes claves externas con actualizaciones
en cascada que hacen referencia a una tabla que tienes que actualizar con
triggers.

Esto es un poco lo mismo que lo que yo digo, pero lo mío es una
solución casera.

Lo que quería decir es que este problema es poco frecuente. A mi me ha
pasado alguna vez al crear vistas actualizables usando triggers.

Ya sé que no es lo mismo, pero en un caso genero un
id que sirve de clave principal de forma artificial y es inmutable
(dejando el NIF como UNIQUE), y en tu caso, se usa un autonumérico
(que no es clave)

Si es clave, pero no primaria.

para solventar esa situación. Yo lo que trato es de
evitar la situación antes de que surja.

Pues no me parece buena idea por que la situación surge muy pocas veces y
cuando surge se soluciona fácilmente.


Saludos

Hola Alfredo:

Hola Juan Diego,

El Wed, 17 Dec 2008 01:03:18 -0800 (PST), Juan Diego Bueno escribió:

> Sí, esto viene a cuento porque yo en aquellos post, decía que generaba
> una clave primaria a partir de otra única. Por ejemplo, no usaba el
> NIF como tal, sino una generada a partir del NIF y usando una
> numeración aleatoria de forma que si alguna vez ese NIF se modificaba,
> se mantuviera la clave principal y si se volvía a introducir el primer
> NIF, se generara una clave principal a partir de él que no coincidiera
> con la anterior (no sé si se me ha entendido, es un pelín retorcido)

Pues sí que es retorcido. ¿Y por que no usar un entero sin más?

Bueno, al final le pegué un meneo al diseño y usaba enteros sin más.
Me dejé de experimentos retorcidos

>> El problema solo ocurre cuando tienes claves externas con actualizaciones
>> en cascada que hacen referencia a una tabla que tienes que actualizar con
>> triggers.

> Esto es un poco lo mismo que lo que yo digo, pero lo mío es una
> solución casera.

Lo que quería decir es que este problema es poco frecuente. A mi me ha
pasado alguna vez al crear vistas actualizables usando triggers.

A mi me daba el mismo problema que a Alex cuando usaba como clave el
NIF, como caso particular, y en casos en los que no podía actualizar
en cascada.

> Ya sé que no es lo mismo, pero en un caso genero un
> id que sirve de clave principal de forma artificial y es inmutable
> (dejando el NIF como UNIQUE), y en tu caso, se usa un autonumérico
> (que no es clave)

Si es clave, pero no primaria.

> para solventar esa situación. Yo lo que trato es de
> evitar la situación antes de que surja.

Pues no me parece buena idea por que la situación surge muy pocas veces y
cuando surge se soluciona fácilmente.

Bueno, las hay mejores, pero también peores. Tampoco me suponía en su
momento mucho esfuerzo generar esas claves artificiales.

Un saludo

"Leonardo Azpurua" wrote:

Aunque, como decimos en mi pueblo, lo único seguro que hay es la muerte.

Y a veces, ni eso...

http://edicionesanteriores.trabajad...muerto.htm

:-)