从int到GUID作为主键移动

时间:2008-09-26 07:40:27

标签: sql sql-server database-design

我使用带有整数主键的几个引用表。现在我想将更改为GUID,使所有引用保持不变。最简单的方法是什么?

谢谢!

加成

我一般都了解这个过程,所以我需要更详细的建议,例如,如何填写新的GUID列。使用默认值newid()是正确的,但对于现有的行是什么?

8 个答案:

答案 0 :(得分:11)

  • 为guid创建一个新列 主表中的值。使用 uniqueidentifier数据类型,制作它 如果没有newid(),则为null 将填充所有现有行。
  • 创建新的uniqueidentifier列 在子表中。
  • 使用exisitng int关系运行update语句以构建公会关系以引用实体。
  • 删除原始的int列。

此外,在数据/索引页面中留出一些空间(指定fillfactor< 100),因为guids不像int identity列那样是顺序的。这意味着插入可以位于数据范围内的任何位置,如果页面已满100%,则会导致页面拆分。

答案 1 :(得分:4)

首先:亲爱的上帝为什么?!?!?

其次,您必须首先将GUID列添加到所有表中,然后根据int值填充它们。完成后,您可以将GUID设置为主键/外键,然后删除int列。

要更新值,您需要执行类似

的操作
  1. 在主键表中设置新GUID
  2. 运行此:
  3. UPDATE foreignTable f
    SET f.guidCol = p.guidCol
    FROM primaryTable p
    WHERE p.intCol = f.intCol
    

答案 2 :(得分:3)

这与实现分布式计算模型的系统相关。如果系统在系统中保留信息时需要知道主键,则使用由 ONE 处理程序维护的自动递增主键会降低系统速度。相反,您需要像GUID生成器这样的机制来创建主键(请记住,主键的真正特征是其唯一性)。因此,我可以扩展多个服务,每个服务创建其主键,彼此独立。

我之前有过这样做的可疑特权,基本上我要做的就是将整个该死的数据库导出为XML。接下来,我有一个Java应用程序,它使用java.util.Random的nextLong()函数将主键替换为新的guid键。之后我将整个东西重新导入数据库。

当然,我第一次尝试导入XML文件时,忘了关闭主键字段的自动编号功能,所以要从错误中吸取教训。我确信有更好的方法可以做到这一点,但这是一种快速而肮脏的方式......它起作用了。如果您想知道,该项目将使应用程序扩展。

答案 3 :(得分:2)

是的,我和Glenn在一起......在发布之前,我真的犹豫发布同样的事情......

为什么你不希望自动增加int主键与GUID分开?它更加灵活,您可以将GUID列编入索引,以便在查询中获得良好的性能......


至于灵活性,我喜欢把自己的身份作为自动增量的内容,因为那时另一个看似独特且主要关键的项目可以改变。

灵活性的一个很好的例子是使用用户名作为主键。即使它们是独一无二的,能够改变它们也是很好的。如果用户使用电子邮件地址作为用户名怎么办?能够更改用户名并使其不影响您的所有查询是一个很大的优点,我怀疑您的GUID也是如此....

答案 4 :(得分:0)

我想,你必须手工制作。或者你可以为它编写一些实用程序。场景应该是:

  • 使用新的“guid”列复制“int”PK / FK列。
  • 为“guid”PK列生成新值。
  • 使用指定值更新“guid”FK列中的值(通过“int”PK查找记录)。
  • 删除带有“int”PK / FK列的引用(关系)。
  • 使用“guid”PK / FK列创建类似的引用(关系)。
  • 删除“int”PK / FK列。

答案 5 :(得分:0)

有趣的是我认为我需要完全相反,因为另一个问题......

How can use SQLBulkCopy on a table with a GUID primary key and default newsequentialid()?

答案 6 :(得分:0)

这是一个非常好的选择。我为我的一个应用程序从longs切换到UUID,我不后悔。如果您使用MS SQL Server,它将包含在标准中(我使用postgresql,它仅包含在8.3中的标准中)。

Glenn Slaven所述,您可以从当前记录中的密钥重新创建UUID。请注意,它们不会是独一无二的,但这样可以很容易地保持关系的完整性。移动后创建的新记录将是唯一的。

答案 7 :(得分:0)

不要做!我们开始使用GUID,现在我们几乎已经完成了作为PK的INTs;我们保留了用于记录目的的GUID(以及一些表,呃,“可协商的关系完整性”;)),但使用int的速度增加是惊人的。

当表行数增加到数百万时,这才真正变得明显,请注意。

到目前为止,我们最大的愚蠢是使用NEWID()作为我们(顺序)日志表的PK - 当我们意识到错误时,有很多令人头疼的事。