它连接到 BI 并合并来自不同数据源的数据，并使该过程更加顺畅。
是否有从没有 Guids 的数据库到没有信息丢失的有 Guids 的版本的最佳迁移策略？
bovium
问问题
5877 次
8 回答
20
请记住，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 )
于 2008-12-12T10:15:37.807 回答
14
在阅读了 Frans Bouma 的答案后进行了编辑，因为我的答案已被接受并因此移至顶部。谢谢，弗兰斯。
GUID 确实具有很好的独特价值，但是由于它们的复杂性，它们并不是真正的人类可读的，这会使支持变得困难。如果您打算使用 GUID，您可能需要考虑在做出选择之前对批量数据操作进行一些性能分析。考虑到如果您的主键是“集群的”，那么 GUID 就不合适了。
这是因为聚集索引会导致在插入/更新时对表中的行进行物理重新排序。由于 GUID 是随机的，因此每次插入都需要移动表中的实际行以便为新行让路。
就我个人而言，我喜欢在我的数据上有两个“键”：
1) 主键
具有聚集主键的唯一数值。这是我系统每行的内部ID，用于唯一标识一行和外键。
如果您使用数据库复制（SQL Server 将自动为合并复制的表添加“rowguid”列），标识可能会导致麻烦，因为标识种子是按服务器实例维护的，并且您会得到重复。
2) 外部密钥/外部 ID/业务 ID
通常，最好还有一个“外部 ID”的附加概念。这通常是具有唯一约束的字符字段（可能包括另一列，例如客户标识符）。
这将是外部接口使用的值，并且会暴露给客户（他们不认可您的内部值）。这个“企业 ID”允许客户使用对他们有意义的值来引用您的数据。
于 2008-12-12T09:22:05.263 回答
4
您可能需要该工具来追溯源以进行审计，尤其是在财务数据方面。
即使您在仓库系统中使用合成密钥（如果您有多个数据源，您几乎肯定会这样做），您仍然需要支持审计。在系统中的表上放置一个“数据源”和“自然键”列，并用源代码和唯一标识源记录的表示填充它们。
如果你这样做，合成键只需要足够宽的整数或数字来存储足够的值（如果 <4b 行，则为整数，如果超过，则为数字）。这意味着它们将比 GUID 更具可读性。
于 2008-12-12T09:02:46.550 回答
2
下面的项目可能有一些用处，或者至少能激发你解决这个问题。
于 2011-02-01T15:27:41.407 回答
1
任何可以唯一标识记录的都是良好的身份数据类型。GUID 通常很好，但如果您实际上有来自源数据的唯一 ID，则它不是最佳标识。GUID 是保证唯一的随机整数值；但是，在集成情况下，您通常希望检测信息的重复，而不仅仅是匹配记录。
于 2008-12-12T08:53:33.870 回答
1
没有“最佳”身份数据类型。各种选项有不同的优点和缺点。我经常使用 GUID，但我必须定期处理断开连接的客户端和合并复制，所以选择是合适的。如果您不必处理复制（即用户在与中央数据库断开连接时添加新记录的情况），自动递增的 int 字段是更好的选择。
于 2008-12-12T14:36:52.077 回答
1
GUID 在数据复制方案中更好，使用“身份”方法，您必须小心不要导致数据库之间复制的数据之间发生冲突。希望这可以帮助。
于 2008-12-19T16:27:45.850 回答
0
我以前根本不喜欢 GUID，但我已经爱上了它。我喜欢它，因为它相对统一且被采用，而且我最终通过使用它编写的代码和维护该代码比我通常编写和维护的代码要少。
它对于存储文件特别有用，在这种情况下，您需要保证文件名是唯一的，在具有大量文件（包括预先存在的文件）的目录中。
于 2008-12-19T16:19:55.320 回答