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

 

http://edu.yesky.com/edupxpt/94/2146594.shtml

　　主键的必要性:

　　有些朋友可能不提倡数据库表必需要主键，但在个人思考中，以为每一个表都应该具备主键，不论是单主键仍是双主键，主键的存在就表明着表结构的完整性，表的记录必须得有惟一区分的字段，主键主要是用于其余表的外键关联，本记录的修改与删除，当咱们没有主键时，这些操做会变的很是麻烦。

　　主键的无心义性:

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

　　主键的选择

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

　　第一:编号做主键

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

　　第二:自动编号主键

　　这种方法也是不少朋友在使用的，就是新建一个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 个字节，与其它那些诸如 4 字节的整数相比要相对大一些。这意味着若是在数据库中使用 uniqueidentifier 键，可能会带来两方面的消极影响:存储空间增大;索引时间较慢。

　　我也不是推荐GUID最好，其实在不一样的状况，咱们均可以采用上面的某一种方式，思考了一些利与弊，也方便你们在进行设计时参考。这些也只是个人一点思考而已，并且可能我知识面限制，会有一些误论在里面，但愿你们有什么想法欢迎讨论。

职场 休闲 数据库

0

分享

微博 QQ 微信

收藏

上一篇：数据库设计准则（第1、第2、第三... 下一篇：数据库中主键和外键的设计原则[转...

不破楼兰

57篇文章，9W+人气，0粉丝

Ctrl+Enter 发布

发布

取消

推荐专栏更多

十年老兵教你练一套正宗的MySQL降龙十八掌

MySQL全通晓

共18章 | 张甦

￥51.00 418人订阅

订   阅

负载均衡高手炼成记

高并发架构之路

共15章 | sery

￥51.00 550人订阅

订   阅

猜你喜欢

个人友情连接 find命令实例 咱们不得不面对的中年职场危机 Java线程：线程的调度-休眠 用光影魔术手制做一寸照片（8张一寸） 职场终极密籍--记个人职业生涯 个人IT职场生涯: 毕业4年，月薪过万 Linux关闭休眠和屏保模式 年薪从0到10万-个人IT职场经验总结 Windows7删除休眠文件hiberfil.sys节省大量C盘空间 致IT同仁 — IT人士常犯的17个职场错误 “跳槽加薪”现象，无奈的职场规则 PostgreSQL VFD机制 支付结算系统如何应对高并发、热点帐户等问题 PostgreSQL WAL解析：构建WAL记录准备 playbook自动安装kafka集群 PostgreSQL的B-tree索引 PostgreSQL pg_rewind实例--could not find previous WA redis geo 地理位置系应用战案例 PostgreSQL逻辑备份pg_dump使用及其原理解析

扫一扫,领取大礼包

0

分享

不破楼兰