2010-09-29 9 views
7

Supongo que todos se topan con este problema de vez en cuando: tiene dos tablas que tienen claves primarias de autonumber que deben fusionarse. Hay muchas buenas razones por las que las claves primarias de autonumber se usan en favor de las claves generadas por aplicaciones, pero la fusión con otras tablas debe ser uno de los mayores inconvenientes.¿Cómo se combinan las tablas con las claves principales del autonumber?

Algunos problemas que surgen son la superposición de los identificadores y las claves externas no sincronizadas. Me gustaría escuchar su enfoque para abordar esto. Siempre me encuentro con problemas, así que tengo mucha curiosidad si alguien tiene algún tipo de solución general.

- EDITAR -

En respuesta a las respuestas que sugieren utilizar guids u otras teclas no numéricas, hay situaciones en las que de antemano que sólo parece una mejor idea de utilizar claves Autonuméricos (y usted Lamento esto más tarde), o estás asumiendo el control del proyecto de otra persona, o obtienes alguna base de datos heredada con la que tienes que trabajar. Así que realmente estoy buscando una solución donde ya no tenga control sobre el diseño de la base de datos.

Respuesta

3

Hm, estoy un poco entusiasmado con la idea de que acabo de poner un comentario en la respuesta de AlexKuznetsov, por lo que voy a hacer una respuesta completa al respecto.

Considerar las mesas para ser nombrado tabla1 y tabla2, con ID1 e ID2 como Autonuméricos claves primarias. Se combinarán en la tabla 3 con id3 (una clave principal que no es autonoma).

Por qué no:

  1. elimine todas las limitaciones de claves externas con tabla1 y tabla2
  2. Para todos los campos de clave externa se refieren a la Tabla 1, ejecutar una UPDATE table SET id1 = id1 * 2, y para campos FK referencia a tabla2, ejecutar una UPDATE table SET id2 = (id2) * 2 + 1
  3. Fill cuadro3 mediante la ejecución de un INSERT INTO table3 SELECT id1 * 2 AS id3, ... FROM table1 UNION ALL SELECT id2 * 2 + 1 AS id3 FROM table2
  4. crear nuevas restricciones de clave externa a la tabla 3

Incluso se puede trabajar con 3 o más tablas, simplemente mediante el uso de un multiplicador superior.

4

Las soluciones incluyen:

  • Use GUID como claves principales en lugar de un campo de identidad más simple. Es muy probable que evite superposiciones, pero los GUID son más difíciles de usar y no funcionan bien con los índices agrupados.

  • Convierta la clave principal en una clave de varias columnas; la segunda columna resolverá los valores solapados al identificar la fuente de los datos fusionados. Portátil, funciona mejor con índices agrupados, pero los desarrolladores odian las claves de varias columnas.

  • Utilice teclas naturales en lugar de pseudokeys.

  • Asigne nuevos valores de clave primaria para una de las tablas fusionadas y coloque estos cambios en cascada en cualquier fila dependiente. Esto cambia una operación de fusión en una operación de ETL. Esta es la única solución que puede usar para datos heredados, si no puede cambiar el diseño de la base de datos.

No estoy seguro de que haya una solución única para todos. Elija uno de estos basado en la situación.

1

Uno de los enfoques estándar (si no el enfoque estándar), donde se está diseñando para tal eventualidad, es utilizar GUID para las claves principales en lugar de números enteros - fusión es entonces relativamente indoloro ya que no se garantizan para encontrar una superposición.

A excepción de un rediseño, sin embargo, creo que está obligado a tener que insertarlo en la tabla, acepta que obtendrá claves primarias nuevas y se asegura de que mantiene la asignación de la ID anterior a la nueva - luego inserte los datos de referencia con FK reasignado, etc. Si sus datos tienen una "clave de negocios" que seguirá siendo única después de la inserción, esto le ahorraría tener que hacer un seguimiento de la asignación.

1

I fyou está seguro de que tiene solo dos de esas tablas, puede tener incluso ID en una tabla (0,2,4,6, ...) e IDs impares en otra (1,3,5,7 , ...)

+0

La pregunta tenía más que ver con una forma genérica, no tanto dónde sabes lo que va a suceder de antemano (porque entonces podrías haber usado guids). – Carvellis

+0

Parece una idea, sin embargo, para calcular NEW_ID = old_id * 2 para la primera tabla y NEW_ID = (old_id * 2) + 1 para la segunda tabla. Si hace esto para todas las tablas que participan todo va a coincidir de nuevo y se puede volver a habilitar las claves foráneas. – thomaspaulb

1

Suponiendo que también tiene una clave natural en las tablas que se fusionarán, el proceso no es difícil. La clave natural se usa para deduplicar y reasignar correctamente cualquier referencia. Puede volver a numerar los valores de la clave sustituta en cualquier momento; esa es una de las principales ventajas de utilizar un sustituto en primer lugar.

Así que no veo esto como un problema con las claves sustitutas, siempre que siempre aplique la clave natural (en realidad prefiero el término "clave comercial"). Si usted no ha conseguido claves de negocio para estas tablas, pues a lo mejor ahora sería un buen momento para rediseñar de manera que todas las claves necesarias se implementan correctamente.

Cuestiones relacionadas