这里正在进行一场冗长的辩论，所以我想听听其他意见。
我有许多带有 uniqueidentifier 聚集 PK 的表。这是否是一个好主意超出了这里的范围（而且它不会很快改变）。
现在，数据库必须合并发布，DEV 提倡使用单独的 rowguid 列，而不是将现有的 PK 标记为 ROWGUIDCOL。
基本上，他们说应用程序永远不应该将仅用于复制的东西带入其域（对他们来说，这只是“DBA 的东西”）。
从性能的角度来看，我认为没有理由添加一个新列来做我可以用现有列做的事情。而且，既然只是“DBA的东西”，为什么不让DBA来选择呢？
我有点理解开发者的观点，但我仍然不同意。
想法？
编辑：我只想补充一点，我在这场辩论中属于少数派，质疑我立场的开发者是我尊重和信任的人。这就是我求助于征求意见的原因。
我也可能遗漏了一些东西，并且可能误解了他们的观点。
我完全同意。但是......主键不仅用于复制（可能应用程序以某种方式使用它）。在这种情况下，这个论点毫无意义。
无论如何，据我所知，这种“DBA 的东西”只有两种方式可以跨越域边界：
如果应用程序正在使用引用该
ROWGUIDCOL列的查询，如下所示：我假设您的所有列都没有这个属性，所以应用程序不会这样做。（顺便说一下，
ROWGUIDCOL这是一个与复制完全不同的概念。恰好合并复制使用它。）主键列将不再可更新。如果应用程序正在执行此操作并且不会进行更改以使用其他算法，则别无选择，只能在表中添加一个新列，因此无需讨论。
除了这些行为之外，该
ROWGUIDCOL属性是完全透明的。您可以添加它，而应用程序永远不会知道。任何类型的数据复制方案都应该对应用程序尽可能透明。我同意。只要 PK 值不需要改变，那么最好使用现有的 uniqueidentifier 列作为 rowguidcol。
“基本上，他们说应用程序永远不应该将仅用于复制的东西带入其域（对于他们来说，这只是“DBA 的东西”）。”
但它不仅仅用于复制。这也是（并且已经）是你的 PK。