ROWGUIDCOLとしてのPKまたは別の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でもあります。