[MySQL]数据库主键设计之思考

泡在网上的日子 / 文 发表于2012-10-14 16:01 次阅读 数据库设计

数据库主键设计之思考一

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

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

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

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

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

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

4.是否采用编号来定义主键

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

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

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

数据库主键设计之思考二


主键的必要性:

    有些朋友可能不提倡数据库表必须要主键,但在我的思考中,觉得每个表都应该具有主键,不管是单主还是双主键,主键的存在就代表着表结构的完整性,表的记录 必须得有唯一区分的字段,主键主要是用于其他表的外键关联,本记录的修改与删除,当我们没有主键时,这些操作会变的非常麻烦。

主键的无意义性:

    我强调主键不应该具有实际的意义,这可能对于一些朋友来说不太认同,比如订单表吧,会有订单编号字段,而这个字段呢在业务实际中本身就是应该具有唯一 性,具有唯一标识记录的功能,但我是不推荐采用订单编号字段作为主键的,因为具有实际意义的字段,具有意义更改的可能性,比如订单编号在刚开始的时候 我们一切顺利,后来客户说订单可以作,并重新生成订单,而且订单号要保持原订单号一致,这样原来的主键就面临危险了。因此,具有唯一性的实际字段也代 表可以作为主键。因此,我推荐是新设一个字段专门用为主键,此主键本身在业务逻辑上不体现,不具有实际意义。而这种主键在一定程序增加了复杂度,所以要视 实际系统的规模大小而定,对于小项目,以后扩展不会很大的话,也查允许用实际唯一的字段作主键的。

主键的选择

    我们现在在思考一下,应该采用什么来作表的主键比较合理,申明一下,主键的设计没有一个定论,各人有各人的方法,哪怕同一个,在不同的项目中,也会采用不同的主键设计原则。

第一:编号作主键

     此方法就是采用实际业务中的唯一字段的编号作为主键设计,这在小型的项目中是推荐这样做的,因为这可以使项目比较简单化,但在使用中却可能带来一些麻 烦,比如要进行编号修改时,可能要涉及到很多相关联的其他表,就象黎叔说的后果很严重”;还有就是上面提到的业务要求允许编号重复时,我们再那么 先知,都无法知道业务将会修改成什么?

第二:自动编号主键

      这种方法也是很多朋友在使用的,就是新建一个ID字段,自动增长,非常方便也满足主键的原则,优点是:数据库自动编号,速度快,而且是增量增长,聚集型主 键按顺序存放,对于检索非常有利;数字型的,占用空间小,易排序,在程序中传递也方便;如果通过非系统增加记录(比如手动录入,或是用其他工具直接在表里 插入新记录,或老系统数据导入)时,非常方便,不用担心主键重复问题。

      缺点:其实缺点也就是来自其优点,就是因为自动增长,在手动要插入 指定ID的记录时会显得麻烦,尤其是当系统与其他系统集成时,需要数据导入时,很难保证原系统的ID不发生主键冲突(前提是老系统也是数字型的);如果其 他系统主键不是数字型那就麻烦更大了,会导致修改主键数据类型了,这也会导致其他相关表的修改,后果同样很严重;就算其他系统也是数字型的,在导入时,为 了区分新老数据,可能想在老数据主键前统一加一个“o”(old)来表示这是老数据,那么自动增长的数字型又面临一个挑战。

第三:Max加一

     由于自动编号存在那些问题,所以有些朋友就采用自己生成,同样是数字型的,只是把自动增长去掉了,采用在Insert时,读取Max值后加一,这种方法可 以避免自动编号的问题,但也存在一个效率问题,如果记录非常大的话,那么Max()也会影响效率的;更严重的是并发性问题,如果同时有两人读到相同的Max后,加一后插入的ID值会重复,这已经是有经验教训的了。

第四:自制加一

     考虑Max加一的效率后,有人采用自制加一,也就是建一个特别的表,字段为:表名,当前序列值。这样在往表中插入值时,先从此表中找到相应表的最大值后加 一,进行插入,有人可能发现,也可能会存在并发处理,这个并发处理,我们可以采用lock线程的方式来避免,在生成此值的时,先Lock,取到值以后,再unLock出来,这样不会有两人同时生成了。这比Max加一的速度要快多了。但同样存在一个问题:在与其他系统集成时,脱离了系统中的生成方法后,很麻 烦保证自制表中的最大值与导入后的保持一致,而且数字型都存在上面讲到的“o”老数据的导入问题。因此在自制加一中可以把主键设为字符型的。字符型的 自制加一我倒是蛮推荐的,应该字符型主键可以应付很多我们意想不到的情况。

第五:GUID主键

    目前一个比较好的主键是采用GUID,当然我是推荐主键还是字符型的,但值由GUID生成,GUID是可以自动生成,也可以程序生成,而且键值不可能重 复,可以解决系统集成问题,几个系统的GUID值导到一起时,也不会发生重复,就算有“o”老数据也可以区分,而且效率很高,在.NET里可以直接使用System.Guid.NewGuid()进行生成,在SQL里也可以使用NewID()生成。

优点是:

    IDENTITY 列相比,uniqueidentifier 列可以通过NewID() 函数提前得知新增加的行ID,为应用程序的后续处理提供了很大方便。

    便于数据库移植,其它数据库中并不一定具有IDENTITY 列,而Guid 列可以作为字符型列转换到其它数据库中,同时将应用程序中产生的GUID 值存入数据库,它不会对原有数据带来影响。

    便于数据库初始化,如果应用程序要加载一些初始数据,IDENTITY 列的处理方式就比较麻烦,而uniqueidentifier 列则无需任何处理,直接用T-SQL 加载即可。

    便于对某些对象或常量进行永久标识,如类的ClassID,对象的实例标识,UDDI 中的联系人、服务接口、tModel标识定义等。

缺点是:

    GUID 值较长,不容易记忆和输入,而且这个值是随机、无顺序的。

    GUID 的值有16 个字节,与其它那些诸如字节的整数相比要相对大一些。这意味着如果在数据库中使用uniqueidentifier 键,可能会带来两方面的消极影响:存储空间增大;索引时间较慢。

    我也不是推荐GUID最好,其实在不同的情况,我们都可以采用上面的某一种方式,思考了一些利与弊,也方便大家在进行设计时参考。这些也只是我的一点思考而已,而且可能我知识面限制,会有一些误论在里面,希望大家有什么想法欢迎讨论。

数据库外键设计之思考
外键的目的:通过数据库去保证数据的完整性,提高关联查询的效率副作用:插入或更新的效率下降。

1。要用:
通过数据库保证数据完成性。两个表关联查询很多的时候,并且数据量很大,可以不考虑插入或更新的效率时候。
2
。可用,可以不用
可以忍受数据不完整性。或认为程序已经可以控制数据的完整性。
两个表关联查询很多的时候,但两个表的数据量不大或两个表关联查询很多,对查询效率不高,对插入或更新的效率要求高,
3
。不要
两个表无任何逻辑关系,对插入或更新效率要求及高

 

 

收藏 赞 (1) 踩 (0)
上一篇:数据库设计中常见表结构的设计技巧
一、树型关系的数据表 不少程序员在进行数据库设计的时候都遇到过树型关系的数据,例如常见的类别表,即一个大类,下面有若干个子类,某些子类又有子类这样的情况。当类别不确定,用户希望可以在任意类别下添加新的子类,或者删除某个类别和其下的所有子类,
下一篇:MySQL数据库中char与varchar性能分析
在数据库中,字符型的数据是最多的,可以占到整个数据库的80%以上。为此正确处理字符型的数据,对于提高数据库的性能有很大的作用。在字符型数据中,用的最多的就是Char与Varchar两种类型。前面的是固定长度,而后面的是可变长度。现在我们需要考虑的是,在
推荐文章
赞助商