主键是否已过时？

Question

主键提供哪些独特功能？

虽然我用舌头牢牢地把脸埋在脸颊上,我的问题很严肃.在任何火焰开始之前,我不是说在没有约束或参照完整性的情况下构建数据库.但是,据我所知,SQL Server可以取消primary key关键字.

• 独特的索引涵盖了唯一性
• 基于列的非可空性涵盖了PK的非可空性要求
• PK不必聚集,所以不是这样
• 外键可以并且通常使用唯一索引而不是PK来实现
• 甚至MSDN也声明创建了一个唯一索引来强制执行PK的唯一性

我确实同意逻辑上一个主键关于数据模型的一些意图,但它是什么？[讽刺]哦,我们确实得到了SSMS在设计桌子时显示的那个小钥匙图标![/讽刺]

---

编辑

从评论中可以看出,我没有像我想的那样清楚地问这个问题.我同意主键从逻辑角度来看很重要.

我不问:

• 我应该为我的PK选择一个int或一个varchar
• PK必须集群化,或者我如何识别应该集群的内容
• 我如何唯一地识别行

我的目的是问"PK提供哪些功能无法合理地使用其他功能实现？" 我不是建议在这里发疯 - 比如使用触发器来强制执行唯一性而不是唯一的约束/索引.合理是一个关键词 - 使用唯一索引/约束似乎非常类似于定义PK.

Answer 1

完全不同的观点:

SQL是一种由ISO标准定义的语言.该标准具有"强制"功能和"可选的一致性"功能.

如果使用某种数据操作语言构建DBMS,则只有在以下情况下才有权将语言称为"SQL":

(a)您已实施标准规定的所有语法("强制性"功能),以及(b)您已实施的所有语言功能(所有强制性功能至少,以及"可选"功能)你"选择了",准确暴露了标准中定义/描述的行为.

"PRIMARY KEY"语法是一个非常古老的特性,它不一定是那些"强制性"的特征之一.抛弃你的语言意味着你不能再合法地调用你的语言SQL.大型商业供应商很可能不会很快做出这样的举动.

Answer 2

将每个表的一个密钥指定为"主要"密钥的想法基本上是多余的,过时的并且在许多方面非常无益.

它是多余的,因为从逻辑上讲,所有键都可以并且确实提供相同的功能.暂且不考虑任何特定DBMS的限制,从逻辑上讲,"主"键享有与同一表中任何其他键完全相同的特性和功能.因此,将一个密钥指定为"主要"仅与数据库设计者或用户希望的一样重要.区别是任意的(这是EFCodd使用的词)和纯粹的心理(CJDate).

该概念已经过时,因为在现代实践中,表格通常具有多于一个密钥,并且对于不同的用户和数据消费者而言,对于同一条数据具有不同的"优选"或"最重要"标识符.例如:最终用户可以识别并使用表中的一个键(通常称为"业务"或"自然"键); 中间层程序员可能对同一个表中的不同密钥更感兴趣(例如"代理"密钥); 另一方面,DBA可能将"聚集"键视为最重要的,或者他可能同样关注具有索引的所有键.因此,首选或最重要的关键取决于视点和预期用途 - 它根本不是刚性结构特征.

至少有两个原因,"主键"概念是无益的.首先,数据库开发工具,DBMS和建模工具的软件供应商遗憾地将各种软件功能附加到指定为"主键"的密钥上.这实际上违背了原始概念.我们不再需要为每个表选择一个对设计者或用户具有一定逻辑意义的键.我们鼓励甚至被迫选择"主要"键来支持X,Y或Z软件中的这个或那个功能,而不考虑其他因素.这是非常令人遗憾的,因为它代表了软件的限制和缺乏灵活性.我们应该可以自由选择每个目的合适的钥匙,而不是仅限于每桌只有一个键的每个目的.

主键无益的最后一个原因是它们是数据库设计中更重要问题的不必要分心.在教育,数据库设计教科书和日常数据管理实践中,主要关键概念往往具有极大的夸大意义.这通常会损害或实际排除更基本的问题,即所有密钥和所有其他完整性约束对于成功的数据库设计和实现同样重要.

我经常争辩说,"主键"一词应该从数据管理词汇表和数据管理软件中弃用和删除.

Answer 3

主键是一个逻辑概念.它是定义实体标识的关键:在Widgets表中,每个单独的Widget都由其主键值区分.PK不是聚集索引(即物理存储属性),也不是唯一约束(即不同的逻辑属性).虽然主键和群集密钥通常重叠,但这只是巧合(PK是一种方便的群集密钥),或者甚至只是疏忽(即使对于给定的工作负载存在更好的候选者,PK也被用作群集密钥).

更改群集密钥是可以在任何时间,在现场,通过操作完成的更改,以更好地适应此存储要求或性能工作负载要求.该应用程序不应该注意到这种变化(在一个理想的世界......).更改PK是一项设计更改,需要在对象标识符更改时修改应用程序的数据模型,并且通常会通过数据模式/应用程序代码进行渗透.

顺便说一下,这个主题已经被问到并且已经在这里回答:

• 聚集索引应该放在什么列？
• 主键是否应始终指定为聚簇索引
• 我应该设计一个主键为varchar或int的表吗？

详细说明PK和UNIQUE约束之间的区别:即使有几个属性具有唯一约束,因此可以作为PK,只有一个是正确的选择,它们不相等.哪一个完全取决于数据模型,哪一个取决于实体以及每个属性代表什么.PK对于DBMS并不重要,DBMS真正关心的是集群密钥和唯一性,而不仅仅是PK.PK适用于您,开发人员和工具集.你不希望每个开发人员指着数据库与它的ORM工具,选择一个不同的独特的键作为实体的身份,然后存储不同的属性作为每一个写代码的身份.您希望所有人都选择相同的主键,因为除了唯一之外,它还有其他属性.一个主要的例子是稳定性,PK值在实体的整个生命周期内是稳定的(如果不是,则没有正确选择PK).

PK提供哪些功能无法合理地使用其他功能实现？

小SSMS图标.说真的,这最终归结为:PK传达了额外的信息,哪些可能的密钥实际上是识别表中实体的密钥.路径依赖确实在今天的PK位置中发挥了重要作用,同意,但如果不是这样,其他一些构造将会起到完全履行传达逻辑模型意图的作用.