让人讨厌的 primaryKey = MAX(Id) + 1 讨厌、讨厌、讨厌

   最近检查代码质量、看到有写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前台调用源码样例程序源码下载之 --- 数据集权限