主键与唯一约束？

我目前正在设计一个全新的数据库.在学校里,我们总是学会在每张桌子上放一把主键.

我阅读了很多文章/讨论/新闻组的帖子,说最好使用唯一约束(也就是某些数据库的唯一索引)而不是PK.

你的观点是什么？

主键实际上只是一个不允许NULL 的候选键.因此,在SQL术语中 - 它与任何其他唯一键没有区别.

但是,对于我们的非理论RDBMS,你应该有一个主键 - 我从来没有听过它的论点.如果该主键是代理键,那么您还应该对自然键具有唯一约束.

离开的重要一点是,你应该对所有候选(无论是自然的还是代理的)键有唯一的约束.然后,您应该选择一个最简单的是在参考外国的关键是你的主键*.

您还应该有一个聚集索引*.这可能是您的主键,或自然键 - 但它不是必须的.您应该根据表的查询用法选择聚簇索引.如果有疑问,主键不是一个糟糕的首选.

虽然从技术上讲,只需要在外键关系中引用一个唯一的键,但是大多数人都喜欢使用主键.事实上,如果某些RDBMS只允许主键引用,我不会感到惊讶.

编辑:有人指出Oracle的术语"聚簇表"和"聚簇索引"与Sql Server不同.相当于我在Oracle-ese中所说的是索引有序表,建议用于OLTP表 - 我认为这是SO问题的主要焦点.我假设如果您负责大型OLAP数据仓库,那么您应该对数据库设计和优化有自己的看法.

你能提供这些文章的参考吗？

我认为没有理由改变尝试过的方法.毕竟,主键是关系数据库的基本设计功能.

使用UNIQUE来达到同样的目的听起来真的很惹我生气.他们的理由是什么？

编辑:我的注意力刚刚回到这个旧答案.也许你所读到的关于PK与UNIQUE的讨论涉及人们制造某种PK的唯一目的是为了强制执行它的唯一性.对此的答案是,如果它是一个键,那么将其设为键,否则使其成为独特的.

主键只是一个候选键(唯一约束),用于特殊处理(自动创建索引等).

我希望那些反对他们的人认为没有理由以不同的方式对待一个密钥.这就是我的立场.

[编辑]显然,即使我自己的答案没有50分,我也无法发表评论.

@chris:我认为没有任何伤害."主键"实际上只是语法糖.我一直都在使用它们,但我当然不认为它们是必需的.需要一个唯一的密钥,是的,但不一定是主密钥.

非常罕见的非规范化会让你想要一个没有主键的表.主键仅根据PK的性质自动具有唯一约束.

如果要保证ADDITION中列的唯一性,则可以使用唯一约束.

总是有PK的规则是好的.

http://msdn.microsoft.com/en-us/library/ms191166.aspx

你应该总是有一个主键.

但是,我怀疑你的问题只是措辞有点误导,你实际上是要问主键是否应该始终是一个自动生成的数字(也称为代理键),或者某个唯一字段是实际有意义的数据(也称为自然关键),像人的SSN,书籍的ISBN等.

这个问题是DB领域的一场古老的宗教战争.

我的看法是,如果自然键确实是唯一的并且永远不会改变,那么它们更可取.但是,你应该小心,即使看起来像SSN可能会在某些情况下改变SSN的东西.