Объединение контактов в таблице SQL без создания повторяющихся записей - PullRequest
1 голос
/ 25 сентября 2008

У меня есть таблица, которая содержит только два столбца - ListID и PersonID. Когда человек объединяется с другим в системе, я должен был обновить все ссылки от человека-источника, чтобы они стали ссылками на человека-адресата.

В идеале я хотел бы назвать что-то простое, как

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

Однако, если в этой таблице уже есть человек-адресат с тем же ListID, что и у исходного человека, будет сделана дублирующая запись. Как я могу выполнить это действие без создания дублированных записей? (ListID, PersonID является первичным ключом)

РЕДАКТИРОВАТЬ: используется несколько ListIDs. Если SourcePerson назначен для ListID 1, 2 и 3, а DestinationPerson назначен для ListID 3 и 4, тогда конечный результат должен иметь четыре строки - DestinationPerson назначен для ListID 1, 2, 3 и 4.

Ответы [ 4 ]

3 голосов
/ 25 сентября 2008
--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
0 голосов
/ 25 сентября 2008

Сначала вы должны подписать destperson на все списки, на которые подписан SourcePerson, и что Destperson еще не подписан. Затем удалите все подписки SourcePersons. Это будет работать с несколькими 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
0 голосов
/ 25 сентября 2008

На самом деле, я думаю, что вы должны вернуться и пересмотреть свой дизайн базы данных, поскольку вы действительно не должны быть в обстоятельствах, когда вы меняете первичный ключ для записи, как вы предлагаете - это подразумевает, что столбец PersonID на самом деле не является подходящим первичным ключом.

Я предполагаю, что ваш PersonID открыт для ваших пользователей, они по какой-то причине перенумеровали свою базу данных, и вы синхронизируете изменения обратно. Это, как правило, плохая идея, поскольку она нарушает контрольные журналы и временную согласованность. В этих обстоятельствах, как правило, лучше использовать свой собственный неизменяемый первичный ключ - обычно идентификатор - и установить PersonID, который пользователи видят в качестве атрибута этого. Это дополнительная работа, но она даст вам дополнительную стабильность и надежность в долгосрочной перспективе.

Хорошее практическое правило заключается в том, что первичный ключ записи не должен передаваться пользователям, где это возможно, и вы должны делать это только после тщательного рассмотрения. Хорошо, я признаюсь, что неоднократно нарушал это сам, но стоит стремиться к тому, где вы можете :-)

0 голосов
/ 25 сентября 2008

Я должен согласиться с Дэвидом Б. Удалите все старые вещи, которые не должны быть там, а затем выполните обновление.

...