문제

ListID와 PersonID라는 두 개의 열만 포함하는 테이블이 있습니다.한 사람이 시스템의 다른 사람과 병합되면 "출처" 사람의 모든 참조를 "대상" 사람에 대한 참조로 업데이트해야 했습니다.

이상적으로는 다음과 같은 간단한 것을 부르고 싶습니다.

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

그러나 대상 사람이 원본 사람과 동일한 ListID를 가진 이 테이블에 이미 존재하는 경우 중복 항목이 생성됩니다.중복 항목을 생성하지 않고 이 작업을 수행하려면 어떻게 해야 합니까?(ListID, PersonID가 기본키입니다)

편집하다:여러 ListID가 사용됩니다.SourcePerson이 ListID 1, 2, 3에 할당되고 DestinationPerson이 ListID 3, 4에 할당된 경우 최종 결과에는 4개의 행, 즉 ListID 1, 2, 3, 4에 할당된 DestinationPerson이 있어야 합니다.

도움이 되었습니까?

해결책

--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

다른 팁

먼저 Sourceperson이 Destperson이 아직 하위 사업을하지 않았다는 것을 구독 한 모든 목록에 Desperson을 구독해야합니다. 그런 다음 모든 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

나는 David B에 동의해야합니다. 거기에 없어야하는 오래된 것들을 모두 제거한 다음 업데이트를 수행하십시오.

실제로, 제안한 대로 레코드의 기본 키를 변경하는 상황에 있어서는 안 되므로 돌아가서 데이터베이스 설계를 다시 고려해야 한다고 생각합니다. 이는 PersonID 열이 실제로는 아니라는 것을 의미합니다. 우선 적절한 기본 키가 필요합니다.

내 생각에는 귀하의 PersonID가 사용자에게 노출되어 어떤 이유로 데이터베이스 번호를 다시 매겼고 변경 사항을 다시 동기화하고 있는 것 같습니다.이는 일반적으로 감사 추적과 시간적 일관성을 깨뜨리기 때문에 좋지 않은 생각입니다.이러한 상황에서는 일반적으로 변경되지 않는 기본 키(일반적으로 ID)를 사용하고 사용자에게 해당 속성으로 표시되는 PersonID를 설정하는 것이 좋습니다.이는 추가 작업이지만 장기적으로 추가적인 일관성과 견고성을 제공합니다.

경험에 따르면 레코드의 기본 키는 가능한 경우 사용자에게 노출되어서는 안 되며 신중하게 고려한 후에만 노출해야 합니다.좋아, 나는 이것을 여러 번 깨뜨렸다고 고백하지만 가능한 한 노력할 가치가 있습니다 :-)

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top