谢谢! 补充 我大致了解这个过程,所以我需要更详细的建议,例如如何填写新的GUID列。使用默认值newid()是正确的,但对于已经存在的行呢?
此外,在数据/索引页中留出一些空间(指定fillfactor < 100),因为guid不像int identity列那样连续。这意味着插入可以出现在数据范围内的任何位置,并且如果您的页面100%满,则会导致页面拆分。
首先:天哪,为什么会这样?!?!
其次,你需要先在所有的表中添加 GUID 列,并基于 int 值填充它们。完成后,你可以将 GUID 设置为主键 / 外键,然后删除 int 列。
要更新值,你需要执行以下操作:
.
UPDATE foreignTable f
SET f.guidCol = p.guidCol
FROM primaryTable p
WHERE p.intCol = f.intCol
是的,我同意Glenn的观点...在他发布之前我也犹豫了一下是否要发表同样的内容...
为什么你不想要一个自动递增的int主键和GUID分开呢?这样更加灵活,而且你可以对GUID列进行索引,这样查询性能会很好...
至于灵活性,我喜欢把我的id作为自动递增的int,因为其他看起来唯一且应该成为主键的内容可以改变。
灵活性的一个很好的例子是如果你使用用户名作为主键。即使它们是唯一的,能够更改它们也是好的。如果用户将电子邮件地址用作用户名怎么办?能够更改用户名并且不影响所有查询是一个大的优点,我认为对于你的GUID也可能是这样的。
我认为你必须手动完成它。或者你可以编写一些实用程序来完成它。场景应该是:
这是一个非常好的选择。我在我的一个应用程序中从longs切换到UUID,我没有后悔。如果您使用MS SQL Server,则已包含在标准中(我使用postgresql,仅从8.3开始包含在标准中)。
如Glenn Slaven所提到的,您可以从当前记录中的键重新创建UUID。请注意,它们将不是唯一的,但这样可以轻松保持关系完整。移动后创建的新记录将是唯一的。
不要这样做!我们最初使用GUID,现在我们几乎完成了将其移动到INT作为PK;我们保留GUID用于记录目的(以及某些表格的“可协商关系完整性”;),但是使用int的速度提高是惊人的。
当表行数超过百万时,这才真正显现出来。
我们最大的愚蠢是将NEWID()用作(顺序)日志表的PK - 当我们意识到错误时,我们非常后悔。