Fusionar contactos en la tabla SQL sin crear entradas duplicadas

Question

Tengo una tabla que contiene solo dos columnas: ListID y PersonID. Cuando una persona se fusiona con otra en el sistema, debía actualizar todas las referencias de la " fuente " persona a ser referencias al " destino " persona.

Idealmente, me gustaría llamar algo simple como

UPDATE MailingListSubscription
SET PersonID = @DestPerson
WHERE PersonID = @SourcePerson

Sin embargo, si la persona de destino ya existe en esta tabla con el mismo ListID que la persona de origen, se realizará una entrada duplicada. ¿Cómo puedo realizar esta acción sin crear entradas duplicadas? (ListID, PersonID es la clave principal)

EDITAR: se utilizan múltiples ID de lista. Si SourcePerson se asigna a ListIDs 1, 2 y 3, y DestinationPerson se asigna a ListIDs 3 y 4, entonces el resultado final debe tener cuatro filas: DestinationPerson asignada a ListID 1, 2, 3 y 4.

Answer 1

--out with the bad
DELETE
FROM MailingListSubscription
WHERE PersonId = @SourcePerson
  and ListID in (SELECT ListID FROM MailingListSubscription WHERE PersonID = @DestPerson)

--update the rest (good)
UPDATE MailingListSubscription
SET PersonId = @DestPerson
WHERE PersonId = @SourcePerson

Answer 2

Primero debe suscribir Destperson a todas las listas a las que SourcePerson está suscrita y que Destperson aún no está subescibida. Luego borre todas las suscripciones de SourcePersons. Esto funcionará con múltiples ListIDs.

Insert into MailingListSubscription
(
   ListID,
   PersonID
)
Select
   ListID,
   @DestPerson
From
   MailingListSubscription as t1
Where
   PersonID = @SourcePerson and
   Not Exists
   (
      Select *
      From MailingListSubscription as t2
      Where
         PersonID = @DestPerson and
         t1.ListID = t2.ListID
   )



Delete From MailingListSubscription
Where
   PersonID = @SourcePerson

Answer 3

Estoy de acuerdo con David B aquí. Elimine todas las cosas antiguas que no deberían estar allí y luego haga su actualización.

Answer 4

En realidad, creo que debería retroceder y reconsiderar el diseño de su base de datos, ya que realmente no debería estar en las circunstancias en las que está cambiando la clave principal de un registro, como lo propone hacer. Esto implica que la columna ID de persona En realidad, no es una clave primaria adecuada en primer lugar.

Supongo que su PersonID está expuesto a sus usuarios, han vuelto a numerar su base de datos por alguna razón y está sincronizando el cambio nuevamente. Esto generalmente es una mala idea, ya que rompe pistas de auditoría y coherencia temporal. En estas circunstancias, generalmente es mejor usar su propia clave principal que no cambia (generalmente una identidad) y configurar el ID de persona que los usuarios ven como un atributo de eso. Es un trabajo adicional, pero le brindará consistencia y robustez adicionales a largo plazo.

Una buena regla general es que la clave principal de un registro no debe exponerse a los usuarios siempre que sea posible y solo debe hacerlo después de una cuidadosa consideración. De acuerdo, confieso haberlo hecho yo mismo en numerosas ocasiones, pero vale la pena esforzarse por encontrar lo que pueda :-)