Guid是数据库的最佳标识数据类型吗？

它与BI和来自不同数据源的数据合并相关联,并使该过程更加顺畅.

是否存在从没有Guids的数据库到没有信息丢失的Guids版本的最佳迁移策略？

请记住,PK的GUID(或'unique_identifier')是一个糟糕的选择,因为许多PK都有聚簇索引(因此所有行都以索引顺序存储在磁盘上).由于GUID是随机的,因此不确定在索引末尾会附加新行,但可以将其插入索引的中间.这会导致磁盘垃圾,因为必须移动行.

如果您考虑guid,至少使用sqlserver 2005或更高版本和NEWSEQUENTIALID()获取PK值,以获得始终大于最后一个的顺序guid,因此始终附加在索引的末尾.如果您没有使用sqlserver(但是例如postgresql或者您正在使用oracle并使用CHAR(32)或其他类型),请考虑使用COMB(请参阅:http://www.informit.com/articles/article.aspx？ p = 25862)

阅读Frans Bouma的答案后编辑,因为我的答案已经被接受,因此被移到了顶部.谢谢,弗兰斯.

GUID确实具有很好的独特价值,但由于它们的复杂性,它们不是真正的人类可读性,这可能使支持变得困难.如果您要使用GUID,您可能需要考虑在做出选择之前对批量数据操作进行一些性能分析.请注意,如果您的主键是"群集",则GUID不合适.

这是因为聚簇索引会导致在插入/更新的表中对行进行物理重新排序.由于GUID是随机的,因此每个插入都需要移动表中的实际行以为新行腾出空间.

就个人而言,我喜欢在我的数据上有两个"键":

1)主键
具有聚簇主键的唯一数字值.这是我系统每行的内部 ID,用于唯一标识行和外键.

如果您正在使用数据库复制,则身份可能会导致问题(SQL Server将自动为合并复制表添加"rowguid"列),因为每个服务器实例都会维护身份种子,并且您将获得重复项.

2)外部密钥/外部ID /业务ID
通常,还优选具有"外部ID"的附加概念.这通常是具有唯一约束的字符字段(可能包括另一列,例如客户标识符).

这将是外部接口使用的值,并将暴露给客户(他们无法识别您的内部值).此"业务ID"允许客户使用对他们有意义的值来引用您的数据.