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

Question

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

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

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

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

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

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

想法？

编辑：我只想补充一点，我在这场辩论中是少数，质疑我立场的开发者是我尊重和信任的人。这就是我求助于征求意见的原因。
我也可能遗漏了一些东西，并且可能误解了他们的观点。

Answer 1

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

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

无论如何，据我所知，这种“DBA 东西”只有两种方法可以跨越域边界：

1. 如果应用程序使用这样的查询来引用ROWGUIDCOL列：

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

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

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

除了这些行为，该ROWGUIDCOL财产是完全透明的。您可以添加它，应用程序永远不会知道。任何类型的数据复制场景都应该对应用程序尽可能透明。

Answer 2

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

Answer 3

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

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