Se acepta comúnmente que las claves principales deben ser inmutables (o lo más estables posible, ya que la inmutabilidad no se puede imponer en la base de datos). Si bien no hay nada que le impida actualizar una clave principal (excepto la restricción de integridad), puede que no sea una buena idea:
Desde el punto de vista del rendimiento:
- Deberá actualizar todas las claves externas que hagan referencia a la clave actualizada. Una sola actualización puede conducir a la actualización de potencialmente muchas tablas/filas.
- Si las claves foráneas no están indexadas (!!), deberá mantener un bloqueo en la tabla de niños para garantizar la integridad. Oracle solo mantendrá el bloqueo por un corto tiempo, pero aun así, esto da miedo.
- Si sus claves foráneas están indexadas (como debería ser), la actualización conducirá a la actualización del índice (eliminar+insertar en la estructura del índice), esto generalmente es más costoso que la actualización real de la tabla base.
- En las tablas ORGANIZATION INDEX (en otros RDBMS, consulte la clave principal agrupada), las filas se ordenan físicamente por la clave principal. Una actualización lógica resultará en una eliminación física+inserción (más costosa)
Otras consideraciones:
- Si se hace referencia a esta clave en cualquier sistema externo (caché de la aplicación, otra base de datos, exportación...), la referencia se romperá al actualizar.
- Además, algunos RDBMS no admiten la ACTUALIZACIÓN EN CASCADA, en particular Oracle.
En conclusión, durante el diseño, generalmente es más seguro usar una clave sustituta en lugar de una clave primaria natural que se supone que no debe cambiar, pero que eventualmente debe actualizarse debido a cambios en los requisitos o incluso a un error de ingreso de datos.
Si absolutamente tiene que actualizar una clave principal con una tabla de niños, vea esta publicación de Tom Kyte para encontrar una solución.
