SQL Server 2005是否会因为使用nvarchar(50)作为主键而不是整数而惩罚我？

我正在考虑改变一些表,使用nvarchar(50)作为主键而不是int主键.使用密钥的int ID确实是无关数据,它是我感兴趣的字符串.会发生什么样的性能影响,或者你在哪里研究它？除了剪切和尝试之外.

你已经遇到了数据库设计的一个主要"神圣战争".您所指的辩论是"代理与自然关键"的争论,只要有RDBMS(就像我所知道的那样),它就一直在肆虐.

辩论基本上归结为是否应该使用代表性密钥(代理,例如IDENTITY列)而不是使用唯一描述记录(自然密钥)的实际数据.

我会说没有"正确"的答案.性能测量是平台的工件,应该通过实验来评估,但性能不太可能是主要关注点.

我认为是代理键的主要参数是主键的不变性.如果您选择使用自然键,则放弃在建立密钥后更改该密钥的选项.你也放弃了在未来的某个时刻可能变得非独特的可能性.出于这些原因,我通常(并非总是)为我的大多数表使用代理键.

然而,正如我所提到的,如果你如此倾向,那么就会有一个长期存在的辩论,其中充满了关于索引策略和正常形式粘附的讨论.

我会谷歌"代理与自然键".以下是一些可以帮助您入门的链接:

系统工程和RDBMS

TechRepublic的

Tony Rogerson的博客

希望这可以帮助.

考虑使用代理键(int主键)作为主键/聚簇索引键.使用nvarchar(50)作为主键/聚簇索引键的问题在于,您的表将按该键排序,这意味着它可能会变得高度碎片化,并且任何其他索引都会有引用此重量的负担首要的关键.

另一个问题是,你可能需要通过这种类型的值来加入其他表,这是一种随着密钥大小的增长而运行的更昂贵的操作.

我认为nvarchar(50)主键很少有意义.

通常,主键应该是代理,除非您有一个小的自然不可变键.可以说,例如,SSN可以被认为是一种自然不可变的密钥.