数据库关于主键的问题

在我们的数据库设计中&＃xff0c;不可逃避的就是数据库表的主键&＃xff0c;可能有很多朋友没有深入思考过&＃xff0c;主键的设计对整个数据库的设计影响很大&＃xff0c;因此我们不得不要重视起来。

主键的必要性:

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

主键的无意义性&＃xff1a;

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

主键的选择

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

第一&＃xff1a;编号作主键

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

第二&＃xff1a;自动编号主键

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

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

第三&＃xff1a;Max加一

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

第四&＃xff1a;自制加一

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

第五&＃xff1a;GUID主键

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

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

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

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

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

缺点是&＃xff1a;

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

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

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