PK를 ROWGUIDCOL로 사용하거나 별도의 rowguid 열을 사용합니까?

여기에 긴 토론이 진행되어 다른 의견을 듣고 싶습니다.

uniqueidentifier 클러스터 PK가있는 많은 테이블이 있습니다. 이것이 좋은 아이디어인지의 여부는 여기서 다루지 않습니다 (그리고 곧 변경되지 않을 것입니다).

이제 데이터베이스를 병합 게시해야하고 DEV는 기존 PK를 ROWGUIDCOL로 표시하는 대신 별도의 rowguid 열을 사용하도록 권장하고 있습니다.

기본적으로 그들은 응용 프로그램이 복제에서만 사용되는 항목을 도메인으로 가져 와서는 안된다고 말합니다 (이것은 단지 "DBA").

성능 관점에서 볼 때 기존 열로 수행 할 수있는 작업을 수행하기 위해 새 열을 추가해야하는 이유가 없습니다. 게다가, 그것은 단지 "DBA 일"이기 때문에, DBA가 선택하게하지 않겠습니까?

나는 DEV의 요점을 이해하지만 여전히 동의하지 않습니다.

생각?

편집 : 나는이 토론에서 소수에 있다고 덧붙이고 싶습니다. 내 입장을 묻는 DEV는 내가 존경하고 신뢰하는 사람들입니다. 이것이 내가 의견을 요구하는 이유입니다.
나도 뭔가 빠졌을 수도 있고 그들의 요점을 오해했을 수도 있습니다.

기본적으로 그들은 응용 프로그램이 복제에서만 사용되는 항목을 도메인으로 가져 와서는 안된다고 말합니다 (이것은 단지 "DBA").

나는 완전히 동의합니다. 그러나 ... 기본 키 는 복제에만 사용되는 것이 아닙니다 (아마도 응용 프로그램은 어떤 식 으로든 사용합니다 ). 이러한 맥락에서 논쟁은 의미가 없다.

어쨌든, 내가 아는 한,이 "DBA 물건"이 도메인 경계를 넘을 수있는 방법은 2 가지뿐입니다.

1. 애플리케이션 ROWGUIDCOL이 다음과 같이 열 을 참조하는 쿼리를 사용중인 경우 :

   DECLARE @a table (id uniqueidentifier ROWGUIDCOL);
   
   SELECT ROWGUIDCOL FROM @a;

   아직이 속성이없는 열이 없다고 가정하므로 응용 프로그램 에서이 작업을 수행하지 않을 것입니다. (그런데 ROWGUIDCOL복제와는 완전히 별개의 개념입니다. 병합 복제에서도 사용됩니다.)

2. 기본 키 열은 더 이상 업데이트 할 수 없습니다. 응용 프로그램이이 일을하고 변화가 다른 알고리즘을 사용하려고하지 않을 경우,이 없습니다 선택의 여지는 있지만, 테이블에 새 열을 추가, 따라서 더 논의가 필요하지 않습니다.

그 행동 이외의 ROWGUIDCOL속성은 완전히 투명합니다. 당신은 그것을 추가 할 수 있으며 응용 프로그램은 알 수 없습니다. 모든 유형의 데이터 복제 시나리오는 가능한 한 응용 프로그램에 투명해야합니다.

동의한다. PK 값을 변경할 필요가없는 한 기존 uniqueidentifier 열을 rowguidcol로 사용하는 것이 좋습니다.

"기본적으로 그들은 응용 프로그램이 복제에서만 사용되는 항목을 도메인으로 가져 와서는 안된다고 말합니다 ("DBA에만 해당 ").

그러나 복제에만 사용되지는 않습니다. 또한 PK이기도합니다.