数据库中表的主键设计原则收藏.doc

"数据库中表的主键设计原则收藏" 在设计数据库表时，主键的设计是非常重要的一步。一个好的主键设计可以提高数据库的性能和可维护性，而一个糟糕的主键设计可能会带来一系列的问题。本文将讨论数据库中表的主键设计原则，并总结出四点重要的设计原则。 是否要采用 GUID 作为主键？GUID 具有唯一性，可以产生全球唯一的值，这是它最大的优势。然而，GUID 值太复杂，不易记忆，且数据太长，影响数据库效率。此外，GUID 的产生不是以一定的次序产生，对于按主键物理排序的数据库来说，如果在记录的前部插入一条记录，可能会导致后面 N 次方的数据条数后移。这将导致数据插入效率因此，GUID 的采用应该要慎重。 是否要采用自动递增的方式？这种方式是非常不可取的。可能是为了方便插入记录时，不必去人为创建主键值。然而，这种方式带来的麻烦要远远胜于这种所谓的"方便"。例如，数据导入不方便，经常会有从另一系统导入数据进来，自动递增的主键，将不允许原表中的 ID 被导入进来。这会导致主键丢失。此外，对于象订单这样的有主外键的表来说，如果订单的"主档表"主键是自动生成的，那么在保存一个订单时，会要求对主档表与明细表同进行事务保存。这过程中，变以复杂而且不可行。 第三，是否要采用 int 型作为主键？以前大家都采用 int 型，都是出来主键都是数字导致的。但是，我们也明白，并不是只是数字的东西就是数字型的。例如电话号码等。因此，对于主键，采用 int 型的优势是速度快，插入、查询时都可能会比其他的方式快。但是我这种快的效果也未必有多明显，例如以 varchar(15) 为例，物理主键排序的数据，会自动以主键进行物理数据排序。因此，即使是字符型的数据，在插入时也会插入到相应的物理位置上，也就是说，在插入时可能会影响一些速度。但在以后的查询中，速度影响不会太明显。 是否采用编号来定义主键？这条原则其实是非常重要的，主键不应具有任何实际意义。这条其实是非常重要，有人就是觉得编号本身是唯一的，可以作为主键用，但可能会为以后带来麻烦。因为带有实际意义的字段，还是存在被修改的可能性。而对于主键最大的忌讳就是修改主键，这可能会导致非常严重的不可估计的后果。 因此，在设计主键时，我们应该遵循以下原则： 1. 主键不应具有任何实际意义。 2. 主键应该是唯一的。 3. 主键值的生成规则，应该按需求进行规则定义。 4. 主键类型可以是字符型的，我们可以定义一个字段存放一个数值，在生成时，自动加一，然后再存回去。 主键的设计是数据库设计中非常重要的一步。我们应该遵循上述原则，设计一个好的主键，提高数据库的性能和可维护性。