数据库主键设计原则

数据库主键设计原则 或许大家都设计过数据库,也为表定义过主键,今天我想阐述的是,应该如何正确的设计一个主键,在以往的一些资料中,都没有提及到主键设计的原则.我为此总结了一下: 1.是否要采用GUID作为主键 用GUID作主键有它的优势与不足.优势是GUID具有唯一

数据库主键设计原则

或许大家都设计过数据库,也为表定义过主键,今天我想阐述的是,应该如何正确的设计一个主键,在以往的一些资料中,都没有提及到主键设计的原则.我为此总结了一下:

1.是否要采用GUID作为主键

用GUID作主键有它的优势与不足.优势是GUID具有唯一性,在任何情况下,可以产生全球唯一的值.这是GUID最大的优势,也方便数据导入,比如要求从另一个系统中把数据导入进来,那么,不用担心,导入时,会导致主键冲突.不足是GUID值太复杂.不易记忆,因为有时,难免我们会用记录的方式,来进行记录判断.而且数据太长,影响数据库效率.GUID的产生不是以一定的次序产生,对于按主键物理排序的数据库来说,如果在记录的前部插入一条记录,可能会导致后面N次方的数据条数后移.这将导致数据插入效率.因此GUID的采用应该要慎重.

2.是否要采用自动递增的方式

对于以前谈到的主键,要求唯一性,因此大家都用自动递增的方式.这样的方式是非常不可取的.可能是为了方便插入记录时,不必去人为创建主键值.以为这样会方便,其实不是的.带来的麻烦要远远胜于这种所谓的"方便".第一:数据导入不方便,经常会有从另一系统导入数据进来,自动递增的主键,将不允许原表中的ID被导入进来.这会导致主键丢失.第二:对于象订单这样的有主外键的表来说,如果订单的"主档表"主键是自动生成的.那么在保存一个订单时,会要求对主档表与明细表同进行事务保存,而此时,先要生成一条订单,然后取出这个订单自动生成的主键,然后再把此作为明细表的一个外键,进行明细的保存.这过程中,将变以复杂而且不可行.事务如何处理.订单主档表插入记录后,要是明细保存时遇到错误,主档表记录还要进行删除.烦.插入成功以后,还要取出产生的最大值.这将是一个严重的浪费.记录多的话会影响速度,而且会存在并行插入.导致获取的记录可能是不正确的. 因此在以上的严重问题下,请不要采用自动递增方式.

3.是否要采用int型作为主键

以前大家都采用int型，都是出来主键都是数字导致的．其实我们也明白．并不是只是数字的东西就是数字型的．比如电话号码等．因此对于主键，采用int型的优势是速度快，插入，查询时都可能会比其他的方式快．但我这种快的效果也未必有多明显，比如以varchar(15)为例，物理主键排序的数据，会自动以主键进行物理数据排序．因此，就算是字符型的数据，在插入时也会插入到相应的物理位置上，也就是说，在插入时可能会影响一些速度．但在以后的查询中，速度影响不会太明显．而我要说的，不采用int型作为主键，不是说，里面不存数据．我还是建议大家在主键中存放数字，这样的排序比较要比夹杂字母的排序来的快，之所以要采用字符型，也是为以后的数据导入作准备，有一天，会要求从其他表导入数据时，可以在导入数据的主键上加一个特定字母来避免与原主键冲突．比如在导入数据的主键前加一个＂Ｎ＂字母．这也就不用担心，要求导入数据表中的主键是数字型还是字符型了．

４．是否采用编号来定义主键

这个问题是老生常谈了．主键设计有个原则，就是主键不应具有任何实际意义．这条其实是非常重要，有人就是觉得编号本身是唯一的，可以作为主键用，但可能会为以后带来麻烦．因为带有实际意义的字段，还是存在被修改的可能性．而对于主键最大的忌讳就是修改主键，这可能会导致非常严重的不可估计的后果．比如学生编号，平时以为永远不会修改，但修改的可能还是会存在．

还有一种，表面上是唯一的，但实际上应该是允许重复的．我举个例子，订单吧，订单编号应该是唯一吧．是的．可是会存在这样的情况，一张原来的订单是因为某个原因，要求订单作废．那好给订单的状态标识为＂cancel＂．然后允许再次录入同样编号的订单．因此．对于这样的情况下在，虽然有效的订单编号只有一个，但在数据库角度会允许编号重复．所以不管如何，还是建议大家为表都建一个没有任何意义的主键，如ＩＤ．

因此，总结一下，我在设计主键，会采用字符型的．不采用自动递增，在新增记录时，系统生成主键值．一般为全数字进行存入，至于主键值的生成规则，可以按需求进行规则定义．如果没有特殊的要求，只是为了保持唯一，可以定义一个字段存放一个数值．在生成时，自动加一．然后再存回去．这也比从一个表中寻找最大值要来的快吧．

好了．我一时就想起这么多．有建议的一起讨论．．

听棠

http://tintown.blogbus.com/