2010-10-01 25 views

Respuesta

2

Respuesta corta: sí se puede. Por supuesto, deberá asegurarse de que el nuevo valor no concuerde con ningún valor existente y que se cumplan otras restricciones (duh).

¿Qué estás tratando de hacer exactamente?

+0

Supongo que fusionaría la base de datos 2 en la base de datos 1, donde cada uno tiene una tabla de usuarios, y en esas 2 tablas, el mismo nombre de usuario tiene una identificación diferente (identificación de autoincrement). –

3

Puede siempre que

  • El valor es único
  • No hay claves externas existentes se violan
1

Usted puede, bajo ciertas circunstancias.

Pero el hecho de que usted considere esto es una fuerte señal de que hay algo mal con su arquitectura: las claves primarias deben ser puramente técnicas y no tienen ningún significado de negocios en absoluto. Entonces nunca debería haber la necesidad de cambiarlos.

Thomas

+2

"Las claves primarias deben ser puramente técnicas y no tienen ningún significado comercial" - esa es su opinión, no es un hecho. El debate sustitutivo vs. el natural no se ha cerrado. –

+1

Aunque estoy de acuerdo en que el debate aún está abierto, este caso es un fuerte argumento para los sustitutos. – DCookie

29

Está comúnmente aceptado que primary keys should be immutable (o as stable as possible desde la inmutabilidad no puede ser ejecutada en la base de datos). Aunque no hay nada que le impedirá actualizar una clave principal (excepto restricción de integridad), puede que no sea una buena idea:

Desde el punto de vista del rendimiento:

  • Usted tendrá que actualizar todos claves externas que hacen referencia a la clave actualizada. Una sola actualización puede conducir a la actualización de potencialmente muchas tablas/filas.
  • Si las claves externas no están indexadas (!!) tendrá que mantener un bloqueo en la tabla de elementos secundarios para garantizar la integridad. Oracle solo mantendrá el bloqueo por un corto tiempo, pero aún así, esto da miedo.
  • Si sus claves foráneas están indexadas (como deberían), la actualización conducirá a la actualización del índice (eliminar + insertar en la estructura de índice), esto generalmente es más caro que la actualización real de la tabla base.
  • En las tablas ORGANIZATION INDEX (en otros RDBMS, vea la clave principal agrupada), las filas se clasifican físicamente por la clave principal. Una actualización lógica dará lugar a un examen físico eliminar insertar + (más caro)

Otras consideraciones:

  • Si se hace referencia a esta clave en cualquier sistema externo (caché de la aplicación, otra base de datos, la exportación ...), la referencia se romperá en la actualización.
  • adicionalmente, algunos RDBMS no son compatibles con CASCADE UPDATE, in particular Oracle.

En conclusión, durante el diseño, generalmente es más seguro utilizar una clave sustituta en lugar de una clave principal natural que se supone no cambiar - pero con el tiempo pueden necesitar ser actualizado debido a las nuevas exigencias o incluso datos error de entrada

Si tiene que actualizar una clave primaria con la tabla de niños, vea this post by Tom Kyte for a solution.

+2

Diría que la estabilidad se cita más comúnmente como un atributo deseable de un PK en lugar de inmutabilidad. [Ejemplos] (http://stackoverflow.com/questions/3632726/what-are-the-design-criteria-for-primary-keys/3668234#3668234) –

+0

@Martin: Entiendo la distinción, pero creo que a * physical * la clave principal (es decir, la que define en la base de datos) debe ser inmutable. La clave principal del * modelo conceptual de datos * debe tener los atributos dados en las respuestas del enlace que proporcionó pero puede ser diferente de la clave física final (familiaridad, por ejemplo, no es IMO un criterio para la clave principal de la tabla actual) Mi respuesta se relaciona con la clave principal del modelo físico. –

+0

+1, especialmente la sugerencia de clave sustituta. – DCookie

6

Los atributos de clave principal son tan actualizables como cualquier otro atributo de una tabla. La estabilidad es a menudo una propiedad deseable de una llave, pero definitivamente no es un requisito absoluto. Si tiene sentido desde una perspectiva comercial actualizar una clave, entonces no hay una razón fundamental por la que no deba hacerlo.

2

Desde el punto de vista de la teoría de base de datos relacional, no debería haber absolutamente ningún problema al actualizar la clave primaria de una tabla, siempre que no haya duplicados entre las claves primarias y que no intente poner un valor NULO en cualquiera de las columnas de clave principal.

Cuestiones relacionadas