PK作为ROWGUIDCOL还是使用单独的rowguid列？

这里正在进行一场激烈的辩论，所以我想听听其他意见。

我有很多带有uniqueidentifier集群PK的表。这是否是一个好主意在这里超出了范围（并且不会很快改变）。

现在，必须合并发布数据库，并且DEV提倡使用单独的rowguid列，而不是将现有PK标记为ROWGUIDCOL。

基本上，他们说应用程序永远不应将仅用于复制的内容带入其域（对于他们来说，这只是“ DBA内容”）。

从性能的角度来看，我没有理由为什么要添加一个新列来执行现有列可以做的事情。而且，由于它只是“ DBA的东西”，为什么不让DBA选择？

我有点理解DEV的观点，但是我仍然不同意。

有什么想法吗？

编辑：我只是想补充一点，在这场辩论中我是少数派，而质疑我立场的DEV是我尊敬和信任的人。这就是我诉诸意见的原因。
我可能还缺少一些东西，可能会误解了他们的观点。

基本上，他们说应用程序永远不应将仅用于复制的内容带入其域（对于他们来说，这只是“ DBA内容”）。

我完全同意。但是......主键是不是只用于复制（大概是应用程序使用它的一些方式）。在这种情况下，该论点毫无意义。

据我所知，无论如何，“ DBA素材”只有两种方式可以越过域边界：

1. 如果应用程序正在使用引用该ROWGUIDCOL列的查询，如下所示：

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

   我假设您的所有列都没有此属性，所以应用程序不会这样做。（顺便说一下，这ROWGUIDCOL是与复制完全不同的概念。碰巧的是，合并复制使用了复制。）

2. 主键列将不再可更新。如果应用程序正在执行此操作，并且不打算使用其他算法进行更改，则别无选择，只能在表中添加新列，因此无需讨论。

除这些行为外，该ROWGUIDCOL属性是完全透明的。您可以添加它，而应用程序将永远不会知道。任何类型的数据复制方案都应对应用程序尽可能透明。

我同意。只要不需要更改PK值，那么最好使用现有的uniqueidentifier列作为rowguidcol。

“基本上，他们说应用程序永远不应将仅由复制使用的东西带入其域（对于他们来说，这只是“ DBA东西”）。”

但是它不仅用于复制。它也是（并且已经是）您的PK。