Fusion de contacts dans une table SQL sans créer d'entrées en double

Question

J'ai une table qui ne contient que deux colonnes - un ListID et un PersonID. Lorsqu'une personne est fusionnée avec une autre personne dans le système, je devais mettre à jour toutes les références à partir de "source". personne à faire référence à la " destination " personne.

Idéalement, j'aimerais appeler quelque chose de simple comme

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

Toutefois, si la personne de destination existe déjà dans cette table avec le même ID de liste que la personne source, une entrée en double sera créée. Comment puis-je effectuer cette action sans créer des entrées en double? (ListID, PersonID est la clé primaire)

EDIT: Plusieurs ListID sont utilisés. Si SourcePerson est affecté aux identifiants 1, 2 et 3 et DestinationPerson à 3 et 4, le résultat final doit comporter quatre lignes - DestinationPerson affecté aux identifiants 1, 2, 3 et 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

Tout d’abord, vous devez souscrire un abonnement à toutes les listes auxquelles SourcePerson est abonné et Destperson n’est pas encore abonné. Supprimez ensuite tous les abonnements SourcePersons. Cela fonctionnera avec plusieurs ListID.

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

Je suis d'accord avec David B ici. Supprimez tous les éléments plus anciens qui ne devraient pas être là, puis effectuez votre mise à jour.

Answer 4

En fait, je pense que vous devriez revenir en arrière et reconsidérer la conception de votre base de données, car vous ne devriez vraiment pas modifier la clé primaire d'un enregistrement comme vous le souhaitez. Cela implique que la colonne PersonID n'est pas réellement une clé primaire appropriée en premier lieu.

Je suppose que votre identifiant personnel est exposé à vos utilisateurs. Ils ont renuméroté leur base de données pour une raison quelconque et vous synchronisez le changement. C'est généralement une mauvaise idée car il casse les traces d'audit et la cohérence temporelle. Dans ces circonstances, il est généralement préférable d'utiliser votre propre clé primaire - généralement une identité - et de configurer l'identifiant personnel que les utilisateurs considèrent comme un attribut. C'est un travail supplémentaire qui vous apportera une cohérence et une robustesse supplémentaires à long terme.

Une bonne règle empirique est que la clé primaire d'un enregistrement ne doit pas être exposée aux utilisateurs dans la mesure du possible et vous ne devez le faire qu'après un examen approfondi. OK, j’avoue que j’ai moi-même rompu à de nombreuses reprises, mais cela vaut la peine de s’efforcer de savoir où vous pouvez :-)