最近检查代码质量、看到有写primaryKey = MAX(Id) + 1的做法，总让我有些不爽，虽然是新闻类的网站，对主键的要求不是很严格，关联的数据也不复杂，但是总觉得这样的做法，不是很妥当。
原因之一：
若这个表里的数据很多很多，索引也没有建立好，MAX(Id)的运行效率不会非常高，当然这样的情况比较少发生，但是有的时候这个做法也会引起一些并发问题，当然是一个表里插入时会很少发生这样的问题，若有相关的子表什么的，很可能会引起并发冲突等，当然我们也不希望总是遇到那种复杂的情况，总的来说不是很稳妥。
原因之二：
很早很早的时候，做OA项目，那时候也没大主意，主键就靠这个产生，主表产生了1、2、3、4、5，然后5被删除了，重新又生成了5这个主键，但是莫名其妙的，5个子表没对上，原因虽然是出在我们程序没处理好，当5被删除时，子表里的数据忘记被删除了，若是子表又有子表，那这个问题就更复杂了，每次写程序都能写得天衣无缝还是比较困难的，当然后来不直接删除数据了，只是打上了删除标记，虽然这个问题被间接的解决了，但是总是觉得这样产生主键的方式不是很妥，总是会引起一些没必要的麻烦。
原因之三：
若一个公司有2个分公司，每个分公司都有自己的信息系统，总公司需要把数据进行合并，这时候大家产生的主键都是1、2、3、4，不好合并数据，把数据直接导入到一起，会引起额外的麻烦，这时候主键是越简单越好，表结构也是越简单越好原则，能直接把数据库放到一个表里，其他什么也不管了是最理想的处理方式。
原因之四：
以前的某个公司，做一个医院的项目，由于系统不稳定，导致给A病人开的药会跑到B病人哪里去，开始测试阶段发现了几次这样的现象发生后，这个系统就被废弃了，这搞不好是要出人命的呀，我估计，其中一个关键问题，就是数据的关联主键没处理好，导致主键产生的算法不严谨，关联关系有漏洞，导致这个项目失败的原因会很大，虽然我没看过人家的源码，也没参与这个项目，但是多年的职业感觉告诉我，主键上出问题了，主外键关系是一个管理系统的命脉。
虽然主外键关系是一个很简单的东西，但是这个东西做得天衣无缝、让人觉得心服口服，效率又高，思路又严谨就很难了。
1：是否能保证唯一性？并发情况下？分布式运行情况下？
2：执行效率问题，主键产生的速度足够快？
3：主键是否能适当保证信息的安全性？ 1，2，3，4，傻瓜都能猜测出来，下一个是5？6？7？
4：主键算法能否支持多数据库，越简单兼容越好。
5：别人是否好调用你的主键产生算法？
6：是否在一定程度上避免了错误产生的可能性，例如程序员比严谨导致的业务上的重大错误，例如医院的那个？
7：将来是否好维护好扩展？
随便说说吧，到目前为止看了很多主键的产生算法、做法，真的做得很圆满，很不容易，把一个简单的东西彻底吃透很不容易，能知道存在哪些问题，哪些不足也很难，天天想着去改进了，天天想着问题会在哪里也很难。
其实很多问题，都在我们的工作中存在，我们需要把工作中的问题，一个个都解决好，避免给客户造成重大损失，能解决工作中的缺陷漏洞才是人才，而不是学到死了，也没做出啥玩意儿来，强很多，学那么多，就是为了在工作中用到，解决工作中的点点滴滴问题，小问题太多了最终就全盘崩溃了。
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 如何控制用户显示的菜单权限
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 在页面中的调用权限讲解
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 数据集权限的调用权限讲解
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 分级管理
一步步教你如何用疯狂.NET架构中的通用权限系统 -- 分级授权
疯狂.NET 通用权限设计 C/S后台管理，B/S前台调用源码样例程序源码下载之 --- 操作权限
疯狂.NET 通用权限设计 C/S后台管理，B/S前台调用源码样例程序源码下载之 --- 角色权限
疯狂.NET 通用权限设计 C/S后台管理，B/S前台调用源码样例程序源码下载之 --- 数据集权限
posted on 2010-04-24 15:03 不仅仅是通用权限设计 阅读(2425) 评论(59) 编辑 收藏
扫一扫
到【灌水乐园】发言
评论
1811204嘎啦兄，有没有什么好的解决方法发出来让小弟学习，学习，你好像在抛砖，但是我没有玉啊
#2楼[楼主] 回复 引用 查看
@贺爱平主要是我砖看到了，暂时没能力把玉拿出来给大家看。
#3楼 回复 引用 查看
说说你的解决方案#4楼 回复 引用 查看
吉日兄可以试一试，当从表记录存在时，主表的记录能被删除吗？我没有试过，我多是做逻辑删除。
#5楼 回复 引用 查看
这个帖子不火，我来喷两句。删除的问题用外键不就行了吗？外键不就是用来做这个用途的吗？
至于主键一般分几种情况
1）单据的编号：按一定规则产生，我一般是用存储过程计算，当然了要控制并发（不复杂）
2）顺序号：很简单就用identity不就行了吗？那么问题来了，我要使用这个顺序号关联呢！！！那就使用类似（1）中的办法，产生一个顺序号。
3）有很多人是用GUID，这个也是个解决办法，不过弊端是：GUID比较大，如果是主键或这索引，是肯定影响效率的。另外就是GUID不能包含规则或者含义（比如类型，比如日期）。
另外说一下：楼主说的原因三，如果做过大型的集团公司项目的人一般都应该知道（如果他项目做成了），在总部范围内，主键或唯一索引的定义基本规则是：分公司代码 + 单据编号（或其他编号）。
#6楼 回复 引用 查看
自己写个种子标识了，搞这么复杂#7楼 回复 引用 查看
对的
自己写一个应该可以满足楼主说的
1，2，5，6，7.
3 其实也并不复杂，可以通过随机的方式解决（不是使用Random）.
4 其实也不是很复杂，但是要支持不同的数据库。肯定要写不同的版本，毕竟不用的数据使用不用的语法和函数，当然有ORM或LINQ就另说了。
#8楼 回复 引用 查看
一般来说单据号与主键是两码事，也不要将主键赋于实际的意义。就楼上兄弟所言，普通的单据号应当是走“流水”，规则与号最好是两个字段。
#9楼 回复 引用 查看
@卡通一下不太明白，单号用流水的方式？
那你主键或者聚集索引用那个字段？用流水？
那你查询的时候是查流水号吗？
真的不是很明白。
#10楼 回复 引用 查看
个人觉得流水号不是逼不得已，最好不要用。为什么？因为流水号唯一的作用就是建立关联（或者简化关联关系）。纯粹是技术实现的需要，对于业务来讲没有任何意义。#11楼 回复 引用 查看
说个例子，象入库单这类单据，由于产品是由各各生产部门存入的，所以要有部门编码(专门一个字段)，同时每个部门都有自己的“流水号”。
在整个仓库的入库明细表中，有一个int字段(自增型)为主键。
在查询的时候，直接检索部门编码与流水号就行了，以主键无关。
#12楼 回复 引用 查看
您的这个看法有些片面。
象医院所挂的号就是流水号，只不过加上了日期、科室等等。
#13楼 回复 引用 查看
@卡通一下那我觉得入库单的结构应该是主/细表结构的。对你说的情况不太明白。
那我觉得主表的主键就应该是入库单编号。
说的简单的情况。
发票，我觉得发票的主键就是发票号就可以。难道还要再增加一个流水号吗？
你那个例子最好能说一下你的数据库结构，否则我不太好理解。
另外为什么查询要用流水号？流水号有什么含义，查询不是应该查日期，产品编号，生产车间，产品规格什么的吗？难道不查这些？就查流水号？？？
#14楼 回复 引用 查看
@卡通一下我这里说明一下，这里的流水就是，1，2没有与其他内容组合使用。
如果组合也算的，几乎大部分系统中的编码都是流水号了。
#15楼 回复 引用 查看
主键的作用是用来保证数据的唯一性。也是我们定义的业务数据唯一性的控制方式，可是用流水号？坦白的将我真的不太理解。希望 卡通 能来个具体点的例子。#16楼 回复 引用 查看
我用Nhibernate从来就没有操心过这个东西。#17楼 回复 引用 查看
@阿水对于主键有各种看法，我一般认为主键就是定位用的，不要赋于实际的意义。
入库单就是入库明细的集合。非要说主从，它应当是从表，而且它与多个主表相关联，也就是它有多个字段是做为外键来存在的。
例如：产品标准是它的主表；部门编码是它的主表；检验员编号是它的主表等等。
其实主从表的功用，还是保证数据的完整性。
#18楼 回复 引用 查看
@阿水你举的发票例子就不对。
发票号不能走流水！它是工商局给定的一组号。
#19楼 回复 引用 查看
说白了，主键不好用Max(id)，可是流水一般是要这么用的。呵呵...
#20楼 回复 引用 查看
阿水，主键是保证记录的唯一性，而不是保证数据的唯一性。
你绕在这了！
#21楼 回复 引用 查看
不理解主键是定位用的，我觉得主键就是控制唯一性的。定位应该用索引，聚集索引。
入库单明细，我也有个自增的字段。不过这个数据对用户来讲是不存在的。他们也不关心。我使用流水号来区分内容一样的记录的。
#22楼 回复 引用 查看
楼主的问题是怎么产生主键？我说一下我的做法：用一个表配置编码规则，用一个存储过程计算产生。
用到目前没发现有什么问题。
#23楼 回复 引用 查看
@卡通一下需要这么咬文嚼字吗？
#24楼 回复 引用 查看
看看我的内容再说吧？我说发票用流水号了吗？
我说发票直接用发票号做主键就行了。
原文奉上：
发票，我觉得发票的主键就是发票号就可以。难道还要再增加一个流水号吗？
#25楼 回复 引用 查看
象先提取一条记录，再更改了部分的数据，最后还是要将更新后的数据返回到数据表，不是要用WHERE子句吗？那主键不就是最好的定位方法了吗？#26楼 回复 引用 查看
这绝不是咬文嚼字，这是两个本质上不同的概念。
呵呵。
#27楼 回复 引用 查看
你的例子有点片面，简单的讲我更新数据是根据条件而不是主键。比如我要把价格低于90块的商品的价格提高5块钱。
至于你说更新一条的例子，坦白的说我觉得就是数据唯一性的体现。就是标示了这个记录不同于其他记录。如果这个是你说的定位作用，那可能是我们的用词不同。对你说的定位作用理解的不清楚！
#28楼 回复 引用 查看
@卡通一下我原来以为你说的定位作用是给SQL的解析器用的呢？
#29楼 回复 引用 查看
其实你的定位是你对主键的一个使用方法，并不是主键的意义或定义或特性。主键就是控制唯一性的，而你定位其实就是用利用了唯一性。#30楼 回复 引用 查看
阿水你说的也是有道理的。批量更新当然不好用主键了，要用一定的逻辑条件，只更新一条记录还是用主键简单。我们说两叉了，呵呵！
#31楼 回复 引用 查看
那么我觉得你的定位的作用对于主键来说是以偏盖全了。因为唯一性的保证所以可以用来定位，但是不是只能用来定位。
唯一性是根本，而你说的定位只是其中的一个用途，不全面，而且两个东西也不对等。
#32楼 回复 引用 查看
是不是在说Guid?#33楼 回复 引用 查看
3）有很多人是用GUID，这个也是个解决办法，不过弊端是：GUID比较大，如果是主键或这索引，是肯定影响效率的。另外就是GUID不能包含规则或者含义（比如类型，比如日期）
#34楼 回复 引用 查看
下班了！哈哈，不过好多回复好像跑题了！闪了#35楼 回复 引用 查看
没错！
除了定位外，更多的是把它做为从表外键来使用。
#36楼 回复 引用 查看
如果非得找抽用数据库生成主键，只能用单独的表记录一个pkvalue。然后用transaction select + update.
如果用max（ID），一出现了并发就立刻完蛋。
但是这些方法性能都很差。最好还是DateTime.ToString("yyyyMMddHHmmssfff")+Ramdom.Next()
#37楼 回复 引用 查看
顺便说一句，用access.Counter / Sqlserver.IDentify / Oracle.Trigger 之类的，也一样纯属找抽。以后项目一旦移植、扩容等，麻烦事一堆。
#38楼 回复 引用 查看
你这样产生的主键包含了太多没用的信息，会影响效率的。
#39楼 回复 引用 查看
存在必然有它的道理，不是效率高低的问题。
例如：
在客户端要同时添加一条主记录和n条从记录，如果主表是用int自增型做主键的，那必然要先获取主表的主键，然后再更新从表的外键后，才能进行数据的添加，这往往要用两个过程，十分的不便；假如，我们在客户端用GUID函数直接生成键值，那就可以一次性地配好主从键，在一个过程中就完成了数据的添加。
#40楼 回复 引用 查看
写点实在的吧 乖#41楼 回复 引用 查看
Max(ID) 适用于绝大多人所做的绝大多数的应用。这个问题早就有定论，不需要再拿出来讨论了吧。#42楼 回复 引用 查看
本人不喜欢这样生成主键,一般用GUID1：是否能保证唯一性？并发情况下？分布式运行情况下？
能不能保证就看如何用了，这个可以在逻辑里加上锁就可以了。
2：执行效率问题，主键产生的速度足够快？
效率问题看情况,并不什么什么功能都需要这么好的效率,对于一些并发不多数据量不大的系统来说不存在效率问题.
3：主键是否能适当保证信息的安全性？ 1，2，3，4，傻瓜都能猜测出来，下一个是5？6？7？
主键猜测就能导致数据不安全,那先要看下是不是逻辑上出了问题.
4：主键算法能否支持多数据库，越简单兼容越好。
标准SQL92的语法大部数据库支持,不过估计有些不支持.
5：别人是否好调用你的主键产生算法？
任何东西都能简单化，封装个function就行了。
6：是否在一定程度上避免了错误产生的可能性，例如程序员比严谨导致的业务上的重大错误，例如医院的那个？
这个和主键没有什么关系,数据约束完整性是逻辑需要保证的,保证不了就是逻辑出现错误.
7：将来是否好维护好扩展？
其实一个主键好不好扩展呢，那就看你封装到什么程度给人用了。
其实能不能用好就看你怎样用，知道利弊就没什么问题。总不能用不好就说这个不好用不爽。
#43楼 回复 引用 查看
我在看到这个时，也是觉得这不是主键的问题。因为要是主键错误，那应当是大面积的错号，而不是个别的，这应当是个别模块的逻辑错误。可吉日却将其归于系统不稳定，非常新颖的说法。再说这样的错误也不会导致项目的失败。
如果吉日确实做过大的系统，那在调试阶段什么笑话都会出现的，没有什么大不了的，一个个的排除呗。
呵呵...
#44楼 回复 引用 查看
的确不是一个好的办法 还是设置自增列稳妥些#45楼[楼主] 回复 引用 查看
这句话，说到我心坎上了，的确有水平的回答，我服了你了。#46楼[楼主] 回复 引用 查看
@卡通一下怎么这么多人，点了反对，没一个推荐的，好奇了
#47楼 回复 引用 查看
这个靠谱#48楼 回复 引用 查看
吉日兄，你还是欠火候！我看文章，是将这两个数加在一起算的，你现在都是8了；要两个都是零，没劲，没人关注！哈哈！
#49楼 回复 引用 查看
种子标识了 删除后,再添加,不就继续累加了嘛..#50楼 回复 引用 查看
岂止是讨厌，简直是罪恶！#51楼 回复 引用 查看
1、如果是逻辑主键，GUID是个不错的选择，有人认为效率低，那可以实际测试一下，没想象的严重。而GUID的讨厌在于太长了，不直观，对开发调试来说有点碍事。2、而用序列或自增量，对数据合并以及备份回复来说，可能是个灾难。
3、个人的意见是根据数据表的性质来。如果是基础数据表，记录不多，变化很少，那就用序列或者自增量；如果是关键业务表，在设计表结构时首先考虑分布式和横向扩充，然后分析是否能提供业务主键（注意，要确定一定以及肯定：主键的所有字段不会改变），如果可以，那么写个存储过程生成主键，否则，GUID挺好的。
#52楼 回复 引用 查看
关于GUID的一些注意点：1、GUID是128位的整数，也就是正常Int32的4倍；
2、GUID用于聚簇索引会到处乱插，产生碎片，一定要注意。不过SQL 2005提供了NEWSEQUENTIALID，可以顺序的生成GUID。
#53楼 回复 引用 查看
@辰我想你可能想说的是Oracle.Sequence。
而且，也不能一棍子把这些自增量打死，如果不出现非常复杂的情况，这些功能还是可以用的。
即便是有移植、灾难恢复、扩容分片这样的情况发生，如果在数据库设计阶段考虑到，制定相应的规则来规避，充分利用这些功能还是很有好处的。比如常用的单据流水号就是不二选择。
#54楼 回复 引用 查看
Mysql的主键好像就这样的。你要用，讨厌都没办法#55楼 回复 引用 查看
有个程序不方便用自增,用一个表存储最大值,用的时候+1,怕并发,于是使用了单例模式写了个类来生成最大值.不知是否大材小用了?!不过修改之后,数据丢失或者自己下面出现别人数据的解决了.一年多了,没再出现过相同问题.
#56楼 回复 引用 查看
晕倒了，
那是不是Sqlserver.IDentify / Oracle.Trigger 这些技术应该被淘汰，取消？为什么微软和ORACLE没发现呢，他们太笨了？
做技术的看问题不应该太狭隘，只盯着自己的一亩三分地。
如果没有开阔的视野，
那么在你的世界里你就是最NB的。
不可能有人比你更NB！！！
可是这么样的最NB有意义吗？
#57楼 回复 引用 查看
求大、求全的思维模式，恰恰是那种“纸上谈兵”人的明显特征！
就象我们每天上班，非要买一部“法拉利”；或许还不行，万一要是桥断了呢？最好换一部水陆两用装甲车；问题是现在经常塞车，那直升飞机就是很实用的了。黑鹰最好，可靠性高，还有一定的防护能力，万一碰上恐怖分子呢......
呵呵！
#58楼 回复 引用 查看
发表一下看法：1、不赞同Sqlserver.IDentify，数据库移植太麻烦，而且主键不容易控制，比如要插入主从明细表，主表的主键生成后要立即使用在附表上。
2、我的办法是：用MAX（ID）+1生成主键，然后存到Dictionary<TableName, PrimaryKey)里，下次使用直接从缓存里取出来再加1，效率比较快，而且避免主键删除会产生重复的问题，获取主键的方法记得加锁