Questions tagged «surrogate-key»

我了解代理/人工密钥的一大好处-它们不会更改，因此非常方便。无论它们是单个字段还是多个字段，只要它们是“人造”字段，都是如此。 但是，有时将自动递增的整数字段用作每个表的主键似乎是一个政策问题。拥有这样的单字段密钥始终是最好的主意吗？为什么（为什么不这样做）？ 明确地说，这个问题不是关于人工还是自然的问题，而是关于所有人工密钥是否应为单一字段的问题

33 database-design  primary-key  surrogate-key 

我是代理键的粉丝。我的发现存在确认偏倚的风险。 我在这里和http://stackoverflow.com上看到的许多问题都使用自然键而不是基于IDENTITY()值的替代键。 我在计算机系统方面的背景告诉我，对整数执行任何比较运算都比比较字符串快。 该评论使我质疑我的信念，因此我认为我将创建一个系统来研究我的论点，即在SQL Server中用作键的整数比字符串快。 由于小型数据集之间的区别可能很小，因此我立即想到了两个表的设置，其中主表具有1,000,000行，而辅助表在主表中的每一行有10行，总共有10,000,000行。辅助表。我的测试的前提是创建两组这样的表，一组使用自然键，一组使用整数键，然后对一个简单的查询运行计时测试，例如： SELECT * FROM Table1 INNER JOIN Table2 ON Table1.Key = Table2.Key; 以下是我作为测试平台创建的代码： USE Master; IF (SELECT COUNT(database_id) FROM sys.databases d WHERE d.name = 'NaturalKeyTest') = 1 BEGIN ALTER DATABASE NaturalKeyTest SET SINGLE_USER WITH ROLLBACK IMMEDIATE; DROP DATABASE NaturalKeyTest; END GO CREATE DATABASE NaturalKeyTest ON …

25 sql-server  sql-server-2012  performance-testing  surrogate-key  natural-key 

对于表之间的外键应该链接到自然键还是代理键，是否存在最佳实践？我真正发现的唯一讨论（除非缺少我的google-fu）是杰克·道格拉斯在这个问题上的答案，他的推理对我来说似乎很合理。我知道有关规则会发生变化的讨论之外，但是在任何情况下都需要考虑这一点。 提出这个问题的主要原因是，我有一个使用带有自然键的FK的遗留应用程序，但是开发者大力推动将其移至OR / M（在我们的例子中为NHibernate），并且一个fork已经产生了一些东西。中断更改，因此我希望使用自然键将它们推回正轨，或者移动旧版应用程序以使用FK的替代键。我的直觉说要恢复原始的FK，但是老实说，我不确定这是否是正确的选择。 我们的大多数表都已经定义了代理键和自然键（尽管有唯一约束和PK），因此在这种情况下，不必添加额外的列对我们来说不是问题。我们正在使用SQL Server 2008，但是我希望这对于任何数据库都足够通用。

14 database-design  foreign-key  surrogate-key  natural-key