Questions tagged «surrogate-key»

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

3
与替代整数键相比,自然键在SQL Server中提供的性能更高还是更低?
我是代理键的粉丝。我的发现存在确认偏倚的风险。 我在这里和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 …

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